\ || \ | "Or": matches if and only if either `- Secure clusters, pods, and applications
- Scan images for vulnerabilities
- Web-based UI for visibility to troubleshoot Kubernetes
- Detect and mitigate threats
- Run compliance reports
**Enterprise teams** who want to scale their Calico Enterprise on-premises deployments by providing more self-service to developers. | - -## Product comparison by feature - -| |
• 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 | -| Packet capture API | Retrieves capture files (pcap format) generated by a packet capture for use with network protocol analysis tools like Wireshark. Packet capture data is visible in the Manager UI and Service Graph. | • TCP 8449 Guardian to Packet Capture API
• TCP 6443 to Kubernetes API server | -| Prometheus API service | Collects metrics from $[prodname] components and makes the metrics available to Manager UI. | • 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 Manager UI | Authenticated users can access the browser-based Manager UI, 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 diff --git a/calico-cloud_versioned_docs/version-20-1/get-started/checklist.mdx b/calico-cloud_versioned_docs/version-20-1/get-started/checklist.mdx deleted file mode 100644 index 1c68da7b20..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/get-started/checklist.mdx +++ /dev/null @@ -1,82 +0,0 @@ ---- -description: Review this checklist before opening a Support ticket. ---- - -# Troubleshooting checklist - -## Check $[prodname] installation - -Installing $[prodname] on your Kubernetes cluster is managed by the $[prodname] operator. The $[prodname] operator is deployed as a Deployment in the `calico-cloud` namespace, and records status in a custom resource named `installer`. - -Check the `installer` status using the following command. - -```bash -kubectl get installer default --namespace calico-cloud -o jsonpath --template '{.status}' -``` - -**Sample output** - -``` -{"clusterName":"my-new-cluster","state":"installing"} -``` - -After `state` is `complete`, $[prodname] is properly installed. - -## Check logs for fatal errors - -Check that the $[prodname] operator is running and that logs do not have any fatal errors. - -```bash -kubectl logs -n calico-cloud deployment/calico-cloud-controller-manager -2022-04-04T14:34:32.472Z INFO controller-runtime.metrics metrics server is starting to listen {"addr": "127.0.0.1:8080"} -2022-04-04T14:34:32.472Z INFO setup starting manager -2022-04-04T14:34:32.472Z INFO setup config {"ccBaseURL": "https://www.dev.calicocloud.io/api", "debug": false, "leader-elect": true} -I0404 14:34:32.472586 1 leaderelection.go:243] attempting to acquire leader lease calico-cloud/c2ad41ce.calicocloud.io... -2022-04-04T14:34:32.472Z INFO controller-runtime.manager starting metrics server {"path": "/metrics"} -I0404 14:34:32.480870 1 leaderelection.go:253] successfully acquired lease calico-cloud/c2ad41ce.calicocloud.io -<...> -``` - -## Check custom resources - -Verify that you have the **installer custom resource**, and that the values are appropriate for your environment. - -```bash -kubectl get installers.operator.calicocloud.io --namespace calico-cloud -o yaml -``` - -```yaml -apiVersion: v1 -items: - - apiVersion: operator.calicocloud.io/v1 - kind: Installer - metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"operator.calicocloud.io/v1","kind":"Installer","metadata":{"annotations":{},"name":"my-new-cluster","namespace":"calico-cloud"}} - creationTimestamp: '2022-04-04T14:34:29Z' - generation: 1 - name: my-new-cluster - namespace: calico-cloud - resourceVersion: '1102' - uid: eb1d1cd0-f01f-47b2-81fe-8eee46dbe712 - status: - clusterName: my-new-cluster - message: '' - resourceVersion: '' - state: installing -kind: List -metadata: - resourceVersion: '' - selfLink: '' -``` - -## Send failed installation diagnostics to Calico Cloud support - -To upload diagnostics about a failed installation to $[prodname] support, run the following command: - -```bash -kubectl patch installer -n calico-cloud default --type merge -p='{"spec":{"uploadDiags":true}}' -``` - - diff --git a/calico-cloud_versioned_docs/version-20-1/get-started/connect-cluster.mdx b/calico-cloud_versioned_docs/version-20-1/get-started/connect-cluster.mdx deleted file mode 100644 index 1ca8b2a106..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/get-started/connect-cluster.mdx +++ /dev/null @@ -1,66 +0,0 @@ ---- -description: Get answers to your questions about connecting to Calico Cloud. ---- - -# What happens when you connect a cluster to Calico Cloud - -Although connecting your cluster to $[prodname] is easy, we also understand you may want details about what happens when your cluster is managed by $[prodname]. We hope this article, along with the other topics in this section, gives you the information you need to install $[prodname] with confidence. If you have other questions, let us know: [Support policy](https://www.tigera.io/legal/calico-cloud-support-policy) or email: feedback@calicocloud.io. - -## What happens when you connect your cluster - -- Your cluster is registered and connected to $[prodname] -- Your Calico open source install is updated with resources for $[prodname] features -- Tigera components and services are added to collect metrics and logs that are sent to the Calico Cloud management plane, which provides the basis for visibility and troubleshooting -- Policies are added to secure communications between Tigera components -- A global threat feed is added to alert on any egress traffic to addresses in the threat feed to protect the cluster -- All of your existing network policies (Kubernetes and Calico) can be found in a single place: the default tier - -After your cluster is connected, it is listed in the Managed Clusters page where you can move between multiple clusters. - - - -## What happens when you disconnect your cluster - -Whether you’ve finished your $[prodname] Trial, or terminated your licensed $[prodname] subscription, we know you want your cluster to remain functional. $[prodname] provides a migration script that returns your cluster to a working state in open-source Calico. The migration script: - -- Removes and cleans up all $[prodname] components and services that have no equivalent in open-source Calico -- Switches the operator configuration to open-source Calico, which migrates your cluster to a version of open-source Calico -- Ensures all Calico policies are migrated to the default tier, or allows you to remove all Calico policies - -For details of the migration script, see [Uninstall $[prodname] from a cluster](../operations/disconnect.mdx). - -## What happens under the covers when you connect your cluster - -### Pre-check - -- Verifies that your cluster can be migrated, and validates that the cluster platform and version is supported by $[prodname] -- Records the number of nodes and other basic attributes of your cluster. This data remains on your system and is used for troubleshooting in case there are issues connecting your cluster. - -### Install and connect - -- Based on the Calico install for your cluster, the manifest is upgraded/migrated to use the $[prodname] Tigera operator. (Note that clusters installed using Helm are currently not supported.) -- Tigera operator installs the required $[prodname] Custom Defined Resources (CRDs), and a standard pull secret to allow access to $[prodname] images -- Installs a Prometheus instance for component metrics (if it doesn’t already exist on the cluster) -- Pushes a license to the cluster so components receive appropriate entitlements -- Adds custom namespaces, service account, and role bindings to support cluster access and permissions to the $[prodname] user interface -- Creates RBAC permissions to access these resources: - - Number of nodes in the cluster and stats for billing purposes - - Policies in the cluster, and pod information -- Registers the cluster so it can connect to $[prodname] -- Creates a global threat feed to alert on any egress traffic to addresses in the threat feed -- Adds policies to secure communication for $[prodname] components, including safeguards that prevent any new network policies from impacting the vital functions of the cluster -- Creates roles and bindings to allow the installer to operate and to allow Calico Cloud to operate after installation. - Each of these objects is given minimal permissions for its specific function. -- Creates roles and bindings for two user types for access to Manager UI: - - **Admin** - full permissions for network policies and $[prodname] resources, and read permissions for namespace and pods - - **User** - read-only/view permissions to same resources above - -## How long does it take to connect a cluster? - -Typically, about 5 minutes. - -## Troubleshooting an installation - -- A checklist to [troubleshoot your installation](checklist.mdx) - -- Additional troubleshooting for the [Tigera Operator](operator-checklist.mdx) diff --git a/calico-cloud_versioned_docs/version-20-1/get-started/index.mdx b/calico-cloud_versioned_docs/version-20-1/get-started/index.mdx deleted file mode 100644 index 45727dc1ff..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/get-started/index.mdx +++ /dev/null @@ -1,43 +0,0 @@ ---- -description: Steps to connect clusters to Calico Cloud and upgrade. -hide_table_of_contents: true ---- - -import { DocCardLink, DocCardLinkLayout } from '/src/___new___/components'; - -# Install and upgrade - -Requirements and guides for connecting your Kubernetes cluster to Calico Cloud. - -## Before you begin - -
* The default for new clusters is `Disabled`. For upgrades for previously connected clusters, the default will retain the previous state. | - | Security Posture Dashboard | `installer.components.securityPosture.state` | `Enabled` (default), `Disabled` | - | 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` (default), `false` | - - ```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 \ - --set installer.components.securityPosture.state=Enabled - ``` - In this example, this command connects the cluster to Calico Cloud with Image Assurance, Runtime Security, and Security Posture Dashboard 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**. - When the status changes to **Connected**, installation is complete and your cluster is connected to Calico Cloud. - -## Additional resources - -* [Calico Cloud troubleshooting checklist](checklist.mdx) -* [Tigera operator troubleshooting checklist](operator-checklist.mdx) diff --git a/calico-cloud_versioned_docs/version-20-1/get-started/install-private-registry.mdx b/calico-cloud_versioned_docs/version-20-1/get-started/install-private-registry.mdx deleted file mode 100644 index 220054fa3d..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/get-started/install-private-registry.mdx +++ /dev/null @@ -1,61 +0,0 @@ ---- -description: Steps to connect your cluster to Calico Cloud. -title: Install using a private registry ---- - -# Connect a cluster to Calico Cloud using a private registry - -You can perform a Helm installation from images stored on a private registry. - -## Prerequisites - -* You have an active Calico Cloud account. You can sign up for a 14-day free trial at [calicocloud.io](https://calicocloud.io). -* You are signed in to the Calico Cloud Manager UI as a user with the **Owner**, **Admin**, or **DevOps** role. -* You have at least one cluster that meets our [system requirements](system-requirements.mdx). -* You have kubectl access to the cluster. -* You have installed Helm 3.0 or later on your workstation. -* You have [added the Calico Cloud images to a private registry](setup-private-registry.mdx), and you have the following information about the registry: - * Registry secret name - :::note - If your private registry requires credentials, create a `calico-cloud` namespace on your cluster. - Then, create an image pull secret and use this name for the **Registry Secret Name**. - ::: - * Image registry - * Image path - - -## Install Calico Cloud using a private registry - -1. From the **Managed Clusters** page, click **Connect Cluster**. -1. In the **Connect a Cluster** dialog, enter a **Cluster Name** and select a **Cluster Type**. -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 **Advanced Options**, and then select both **Install via helm** and **Private registry**. -1. Enter the **Registry Secret Name**, **Image registry**, and **Image path**. -1. Click **Connect** to generate a unique Helm installation command. Copy the command. -1. Optional: To make changes to what features are enabled during installation, paste the command to a text editor and append the `--set` option any of the following key-value pairs. - You can change these options only by reinstalling or upgrading Calico Cloud and changing the values. - - | Feature | Key | Values | - |---------|-----|--------| - | Image Assurance | `installer.components.imageAssurance.state` | `Enabled` (default), `Disabled` | - | 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. | - | Security Posture Dashboard | `installer.components.securityPosture.state` | `Enabled` (default), `Disabled` | - | 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` (default), `false` | - - ```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:5kdv6siag:ifk1uwruwlgp7vzn7ecijt5zjbf5p9p1il1ag8877ylwjo4muu19wzg2g8x5qa7x --set installer.clusterName=my-cluster --set installer.calicoCloudVersion=v19.1.0 \ - --set installer.components.imageAssurance.state=Enabled \ - --set installer.components.runtimeSecurity.state=Enabled \ - --set installer.components.securityPosture.state=Enabled - ``` - In this example, this command connects the cluster to Calico Cloud with Image Assurance, Runtime Security, and Security Posture Dashboard 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**. - When the status changes to **Connected**, installation is complete and your cluster is connected to Calico Cloud. - -## Additional resources - -* [Calico Cloud troubleshooting checklist](checklist.mdx) -* [Tigera operator troubleshooting checklist](operator-checklist.mdx) \ No newline at end of file diff --git a/calico-cloud_versioned_docs/version-20-1/get-started/operator-checklist.mdx b/calico-cloud_versioned_docs/version-20-1/get-started/operator-checklist.mdx deleted file mode 100644 index 4851ce1e10..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/get-started/operator-checklist.mdx +++ /dev/null @@ -1,679 +0,0 @@ ---- -description: Additional troubleshooting for the Tigera operator. ---- - -# Tigera operator troubleshooting checklist - -If you have issues getting your cluster up and running, use this checklist. - -- [Check installation start errors](#check-installation-start-errors) -- [Check Calico Cloud installation](#check-calico-cloud-installation) -- [Check logs for fatal errors](#check-logs-for-fatal-errors) -- [Check custom resources](#check-custom-resources) -- [Check pod capacity](#check-pod-capacity) -- [Check Manager UI dashboard for traffic](#check-manager-ui-dashboard-for-traffic) - -## Check installation start errors - -Are you seeing any of these issues at the start of installation? - -### [ERROR] Detected plugin ls: No such file or directory, it is currently not supported - -The cluster you are using to install $[prodname] does not have a CNI plugin installed, the CNI is incompatible. If your cluster has functional pod networking and you see this message, it is likely that kubelet has been configured to use kubenet networking, which is not compatible with $[prodname]. You can use a different cluster, or re-create your cluster with [compatible networking](system-requirements.mdx). - -### $[prodname] cannot be connected to a cluster with FIPS mode enabled - -At this time, FIPS mode is not supported in $[prodname]. Disable FIPS mode in the cluster and install again. - -### Install script is taking a long time - -If you are migrating a large cluster from a previous manifest-based Calico install, the script can take some time; this is normal. - -But, it could also mean that your cluster has an incompatibility. Go to the next step [Check Calico Cloud installation](#check-calico-cloud-installation). - -## Check Calico Cloud installation - -Installing $[prodname] on your Kubernetes cluster is managed by the Tigera operator. The Tigera operator is deployed as a ReplicaSet in the `tigera-operator` namespace, and records status in a custom resource named, `tigerastatus`. The operator get its configuration from several Custom Resources (CRs); the central one is the Installation CR. - -Check `tigerastatus` using the following command. - -```bash -kubectl get tigerastatus -``` - -**Sample output** - -``` -NAME AVAILABLE PROGRESSING DEGRADED SINCE -apiserver True False False 10m -calico True False False 11m -cloud-core True False False 11m -compliance True False False 9m39s -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. - -```bash -kubectl get tigerastatus -error: the server doesn't have a resource type "tigerastatus" -``` - -**Issue: $[prodname] components are missing or are degraded** - -If some of the $[prodname] components are Available = FALSE or DEGRADED = TRUE, run the following command and contact Support with the following output. - -```bash -kubectl get tigerastatus -o yaml -``` - -:::note - -If you are using the **AWS or Azure CNI plugin**, a degraded state is likely because you do not have enough pod capacity on your nodes. To fix this, see [Check pod capacity](#check-pod-capacity). - -::: - -**Sample output** - -In the following example, the typha component has an issue because it is showing `AVAILABLE: FALSE`, and `DEGRADED: TRUE`. To understand details of $[prodname] components, see [Deep dive into custom resources](#deep-dive-into-custom-resources). - -```yaml -apiVersion: v1 -items: - - apiVersion: operator.tigera.io/v1 - kind: TigeraStatus - metadata: - creationTimestamp: '2020-12-30T17:13:30Z' - generation: 1 - managedFields: - - apiVersion: operator.tigera.io/v1 - fieldsType: FieldsV1 - fieldsV1: - f:spec: {} - f:status: - .: {} - f:conditions: {} - manager: operator - operation: Update - time: '2020-12-30T17:16:20Z' - name: calico - resourceVersion: '8166' - selfLink: /apis/operator.tigera.io/v1/tigerastatuses/calico - uid: 39a8a2d0-2074-418c-b52d-0baa0a48f4a1 - spec: {} - status: - conditions: - - lastTransitionTime: '2020-12-30T17:13:30Z' - status: 'False' - type: Available - - lastTransitionTime: '2020-12-30T17:13:30Z' - message: DaemonSet "calico-system/calico-node" is not yet scheduled on any nodes - reason: Not all pods are ready - status: 'True' - type: Progressing - - lastTransitionTime: '2020-12-30T17:13:30Z' - message: 'failed to wait for operator typha deployment to be ready: waiting - for typha to have 4 replicas, currently at 3' - reason: error migrating resources to calico-system - status: 'True' - type: Degraded -kind: List -metadata: - resourceVersion: '' - selfLink: '' -``` - -## Check logs for fatal errors - -Check that the Tigera operator is running and that logs do not have any fatal errors. - -```bash -kubectl get pods -n tigera-operator -``` - -``` -NAME READY STATUS RESTARTS AGE -tigera-operator-8687585b66-68gmr 1/1 Running 0 139m -``` - -```bash -kubectl logs -n tigera-operator tigera-operator-8687585b66-68gmr -``` - -``` -2020/12/30 17:38:54 [INFO] Version: 90975f4 -2020/12/30 17:38:54 [INFO] Go Version: go1.14.4 -2020/12/30 17:38:54 [INFO] Go OS/Arch: linux/amd64 -{"level":"info","ts":1609349935.2848425,"logger":"setup","msg":"Checking type of cluster","provider":""} -{"level":"info","ts":1609349935.2868738,"logger":"setup","msg":"Checking if TSEE controllers are required","required":true} -<...> -``` - -## Check custom resources - -Verify that you have the **installation custom resource**, and that the values are appropriate for your environment. - -```bash -kubectl get installation.operator.tigera.io default -o yaml -``` - -```yaml -apiVersion: operator.tigera.io/v1 -kind: Installation -metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"operator.tigera.io/v1","kind":"Installation","metadata":{"annotations":{},"name":"default"},"spec":{"imagePullSecrets":[{"name":"tigera-pull-secret"}],"variant":"TigeraSecureEnterprise"}} - creationTimestamp: '2021-01-20T19:50:23Z' - generation: 2 - managedFields: - - apiVersion: operator.tigera.io/v1 - fieldsType: FieldsV1 - fieldsV1: - f:metadata: - f:annotations: - .: {} - f:kubectl.kubernetes.io/last-applied-configuration: {} - f:spec: - .: {} - f:imagePullSecrets: {} - f:variant: {} - manager: kubectl - operation: Update - time: '2021-01-20T19:50:23Z' - - apiVersion: operator.tigera.io/v1 - fieldsType: FieldsV1 - fieldsV1: - f:spec: - f:calicoNetwork: - .: {} - f:bgp: {} - f:hostPorts: {} - f:ipPools: {} - f:mtu: {} - f:multiInterfaceMode: {} - f:nodeAddressAutodetectionV4: - .: {} - f:firstFound: {} - f:cni: - .: {} - f:ipam: - .: {} - f:type: {} - f:type: {} - f:componentResources: {} - f:flexVolumePath: {} - f:nodeUpdateStrategy: - .: {} - f:rollingUpdate: - .: {} - f:maxUnavailable: {} - f:type: {} - f:status: - .: {} - f:variant: {} - manager: operator - operation: Update - time: '2021-01-20T19:55:10Z' - name: default - resourceVersion: '5195' - selfLink: /apis/operator.tigera.io/v1/installations/default - uid: 016c3f0b-39f0-48a0-9da8-a59a81ed9128 -spec: - calicoNetwork: - bgp: Enabled - hostPorts: Enabled - ipPools: - - blockSize: 26 - cidr: 10.42.0.0/16 - encapsulation: IPIP - natOutgoing: Enabled - nodeSelector: all() - mtu: 0 - multiInterfaceMode: None - nodeAddressAutodetectionV4: - firstFound: true - cni: - ipam: - type: Calico - type: Calico - componentResources: - - componentName: Node - resourceRequirements: - requests: - cpu: 250m - flexVolumePath: /usr/libexec/kubernetes/kubelet-plugins/volume/exec/nodeagent~uds - imagePullSecrets: - - name: tigera-pull-secret - nodeUpdateStrategy: - rollingUpdate: - maxUnavailable: 1 - type: RollingUpdate - variant: TigeraSecureEnterprise -status: - variant: TigeraSecureEnterprise -``` - -Verify that you have the following custom resources. In the default installation, there is no configuration information. - -**Check API server** - -```bash -kubectl get apiserver.operator.tigera.io tigera-secure -``` - -``` -NAME AGE -tigera-secure 85m -``` - -**Check cloud core** - -```bash -kubectl get cloudcore.operator.tigera.io tigera-secure -``` - -``` -NAME AGE -tigera-secure 88m -``` - -**Check compliance** - -```bash -kubectl get compliance.operator.tigera.io tigera-secure -``` - -``` -NAME AGE -tigera-secure 90m -``` - -**Check intrusion detection** - -```bash -kubectl get intrusiondetection.operator.tigera.io tigera-secure -``` - -``` -NAME AGE -tigera-secure 93m -``` - -**Check log collector** - -```bash -kubectl get logcollector.operator.tigera.io tigera-secure -``` - -``` -NAME AGE -tigera-secure 96m -``` - -**Check management cluster** - -```bash -kubectl get ManagementClusterConnection.operator.tigera.io tigera-secure -o yaml -``` - -```yaml -apiVersion: operator.tigera.io/v1 -kind: ManagementClusterConnection -metadata: - annotations: - kubectl.kubernetes.io/last-applied-configuration: | - {"apiVersion":"operator.tigera.io/v1","kind":"ManagementClusterConnection","metadata":{"annotations":{},"name":"tigera-secure"},"spec":{"managementClusterAddr":"
- Amazon VPC CNI | -| Azure Kubernetes Service | - Calico Open Source 3.20 or later
- Azure CNI | -| Google Kubernetes Engine | - Calico Open Source 3.20 or later
- GKE CNI | -| Rancher Kubernetes Engine 2 | - Calico Open Source 3.20 or later | - -:::note - -The Kubernetes distributions listed above are those that Tigera currently tests and supports for Calico Cloud. -You may be able to connect clusters on other distributions with Calico Open Source installed as the CNI. -For more information about connecting other cluster types to Calico Cloud, [contact Support](https://tigeraio.my.site.com/community/s/login/). - -::: - -## Kubernetes versions - -Your Kubernetes distribution must be based on one of the following Kubernetes versions: -* Kubernetes 1.30 -* Kubernetes 1.29 -* Kubernetes 1.28 - -## Architectures - -Calico Cloud can be installed on nodes based on the following chip architectures: -* x86-64 -* ARM64 - -## Browser support for the Manager UI web console - -To access the Manager UI web console, you can use latest two versions of the following web browsers: -* Chrome -* Safari - -## Kubernetes reconcilers - -* $[prodname] cannot be usually be installed on clusters that are managed by any kind of Kubernetes reconciler (for example, Addon-manager). To verify, look for an annotation called `addonmanager.kubernetes.io/mode` on either of the following resources. (The resources may not exist). - - * `tigera-operator` deployment in the `tigera-operator` namespace - * `calico-node` daemonset in the `kube-system` namespace - - If the following command finds addonmanager on either of the resources, then Addon-manager is being used. Find a different cluster to use. - - ```bash - kubectl get
- IP in IP overlay with BGP routing
- Cross-subnet support and MTU setting for VXLAN
- IPv6 and dual stack
- Dual-ToR
- Service advertisement
- Multiple networks to pods | -| 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 | -| Dataplane | - eBPF is a Linux-based feature | - -## $[prodname] BGP networking limitations - -If you are using $[prodname] with BGP, note these current limitations with Windows. - -| Feature | Limitation | -| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| IP mobility/ borrowing | $[prodname] IPAM allocates IPs to host in blocks for aggregation purposes.
If the IP pool is full, nodes can also "borrow" IPs from another node's block. In BGP terms, the borrower then advertises a more specific "/32" route for the borrowed IP and traffic for that IP is only routed to the borrowing host.
Windows nodes do not support this borrowing mechanism; they will not borrow IPs even if the IP pool is full and they mark their blocks so that Linux nodes will not borrow from them. | -| IPs reserved for Windows | $[prodname] IPAM allocates IPs in CIDR blocks. Due to networking requirements on Windows, four IPs per Windows node-owned block must be reserved for internal purposes.
For example, with the default block size of /26, each block contains 64 IP addresses, 4 are reserved for Windows, leaving 60 for pod networking.
To reduce the impact of these reservations, a larger block size can be configured at the IP pool scope (before any pods are created). | -| Single IP block per host | $[prodname] IPAM is designed to allocate blocks of IPs (default size /26) to hosts on demand. While the $[prodname] CNI plugin was written to do the same, kube-proxy for Windows currently only supports a single IP block per host.
To work around the default limit of one /26 per host there some options:
- Use $[prodname] BGP networking with the kubernetes datastore. In that mode, $[prodname] IPAM is not used and the CNI host-local IPAM plugin is used with the node's Pod CIDR.
To allow multiple IPAM blocks per host (at the expense of kube-proxy compatibility), set the `windows_use_single_network` flag to `false` in the `cni.conf.template` before installing $[prodname]. Changing that setting after pods are networked is not recommended because it may leak HNS endpoints. | -| IP-in-IP overlay | $[prodname]'s IPIP overlay mode cannot be used in clusters that contain Windows nodes because Windows does not support IP-in-IP. | -| NAT-outgoing | $[prodname] IP pools support a "NAT outgoing" setting with the following behaviour:
- Traffic between $[prodname] workloads (in any IP pools) is not NATted.
- Traffic leaving the configured IP pools is NATted if the workload has an IP within an IP pool that has NAT outgoing enabled. $[prodname] honors the above setting but it is only applied at pod creation time. If the IP pool configuration is updated after a pod is created, the pod's traffic will continue to be NATted (or not) as before. NAT policy for newly-networked pods will honor the new configuration. $[prodname] automatically adds the host itself and its subnet to the NAT exclusion list. This behaviour can be disabled by setting flag `windows_disable_host_subnet_nat_exclusion` to `true` in `cni.conf.template` before running the install script. | -| Service IP advertisement | This $[prodname] feature is not supported on Windows. | - -### Check your network configuration - -If you are using a networking type that requires layer 2 reachability (such as $[prodname] with a BGP mesh and no peering to your fabric), you can check that your network has layer 2 reachability as follows: - -On each of your nodes, check the IP network of the network adapter that you plan to use for pod networking. For example, on Linux, assuming your network adapter is eth0, you can run: - -``` -$ ip addr show eth0 - 2: eth0:
For example, with the default block size of /26, each block contains 64 IP addresses, 4 are reserved for Windows, leaving 60 for pod networking.
To reduce the impact of these reservations, a larger block size can be configured at the IP pool scope (before any pods are created). | -| Single IP block per host | $[prodname] IPAM is designed to allocate blocks of IPs (default size /26) to hosts on demand. While the $[prodname] CNI plugin was written to do the same, kube-proxy currently only supports a single IP block per host.
To allow multiple IPAM blocks per host (at the expense of kube-proxy compatibility), set the `windows_use_single_network` flag to `false` in the `cni.conf.template` before installing $[prodname]. Changing that setting after pods are networked is not recommended because it may leak HNS endpoints. | - -## Routes are lost in cloud providers - -If you create a Windows host with a cloud provider (AWS for example), the creation of the vSwitch at $[prodname] install time can remove the cloud provider's metadata route. If your application relies on the metadata service, you may need to examine the routing table before and after installing $[prodname] to reinstate any lost routes. - -## VXLAN limitations - -**VXLAN support** - -- Windows 1903 build 18317 and above -- Windows 1809 build 17763 and above - -**Configuration updates** - -Certain configuration changes will not be honored after the first pod is networked. This is because Windows does not currently support updating the VXLAN subnet parameters after the network is created so updating those parameters requires the node to be drained: - -One example is the VXLAN VNI setting. To change such parameters: - -- Drain the node of all pods -- Delete the $[prodname] HNS network: - - ```powershell - Import-Module -DisableNameChecking $[rootDirWindows]\libs\hns\hns.psm1 - Get-HNSNetwork | ? Name -EQ "$[prodname]" | Remove-HNSNetwork - ``` - -- Update the configuration in `config.ps1`, run `uninstall-calico.ps1` and then `install-calico.ps1` to regenerate the CNI configuration. - -## Pod-to-pod connections are dropped with TCP reset packets - -Restarting Felix or changes to policy (including changes to endpoints referred to in policy) can cause pod-to-pod connections to be dropped with TCP reset packets when one of the following occurs: - -- The policy that applies to a pod is updated -- Some ingress or egress policy that applies to a pod contains selectors and the set of endpoints that those selectors match changes - -Felix must reprogram the HNS ACL policy attached to the pod. This reprogramming can cause TCP resets. Microsoft has confirmed this is a HNS issue, and they are investigating. - -## Service ClusterIPs incompatible with selectors on pod IPs in network policy - -**Windows 1809 prior to build 17763.1432** - -On Windows nodes, kube-proxy unconditionally applies source NAT to traffic from local pods to service ClusterIPs. This means that, at the destination pod, where policy is applied, the traffic appears to come from the source host rather than the source pod. In turn, this means that a network policy with a source selector matching the source pod will not match the expected traffic. - -## Network policy and using selectors - -Under certain conditions, relatively simple $[prodname] policies can require significant Windows dataplane resources, that can cause significant CPU and memory usage, and large policy programming latency. - -We recommend avoiding policies that contain rules with both a source and destination selector. The following is an example of a policy that would be inefficient. The policy applies to all workloads, and it only allows traffic from workloads labeled as clients to workloads labeled as servers: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: calico-dest-selector -spec: - selector: all() - order: 500 - ingress: - - action: Allow - destination: - selector: role == "webserver" - source: - selector: role == "client" -``` - -Because the policy applies to all workloads, it will be rendered once per workload (even if the workload is not labeled as a server), and then the selectors will be expanded into many individual dataplane rules to capture the allowed connectivity. - -Here is a much more efficient policy that still allows the same traffic: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: calico-dest-selector -spec: - selector: role == "webserver" - order: 500 - ingress: - - action: Allow - source: - selector: role == "client" -``` - -The destination selector is moved into the policy selector, so this policy is only rendered for workloads that have the `role: webserver` label. In addition, the rule is simplified so that it only matches on the source of the traffic. Depending on the number of webserver pods, this change can reduce the dataplane resource usage by several orders of magnitude. - -## Network policy with tiers - -Because of the way the Windows dataplane handles rules, the following limitations are required to avoid performance issues: - -- Tiers: maximum of 5 -- `pass` rules: maximum of 10 per tier -- If each tier contains a large number of rules, and has pass rules, you may need to reduce the number of tiers further. - -## Flow log limitations - -$[prodname] supports flow logs with these limitations: - -- No packet/bytes stats for denied traffics -- Inaccurate `num_flows_started` and `num_flows_completed` stats with VXLAN networking -- No DNS stats -- No Http stats -- No RuleTrace for tiers -- No BGP logs - -## DNS Policy limitations - -:::note - -DNS Policy is a tech preview feature. Tech preview features may be subject to significant changes before they become GA. - -::: - -$[prodname] supports DNS policy on Windows with these limitations: - -- It could take up to 5 seconds for the first TCP SYN packet to go through, for a connection to a DNS domain name. This is because DNS policies are dynamically programmed. The first TCP packet could be dropped since there is no policy to allow it until $[prodname] detects domain IPs from DNS response and programs DNS policy rules. The Windows TCPIP stack will send SYN again after TCP Retransmission timeout (RTO) if previous SYN has been dropped. -- Some runtime libraries do not honour DNS TTL. Instead, they manage their own DNS cache which has a different TTL value for DNS entries. On .NET Framework, the value to control DNS TTL is ServicePointManager.DnsRefreshTimeout which has default value of 120 seconds - [DNS refresh timeout](https://docs.microsoft.com/en-us/dotnet/api/system.net.servicepointmanager.dnsrefreshtimeout). It is important that $[prodname] uses a longer TTL value than the one used by the application, so that DNS policy will be in place when the application is making outbound connections. The configuration item “WindowsDNSExtraTTL” should have a value bigger than the maximum value of DNS TTL used by the runtime libraries for your applications. -- Due to the limitations of Windows container networking, a policy update could have an impact on performance. Programming DNS policy may result in more policy updates. Setting “WindowsDNSExtraTTL” to a bigger number will reduce the performance impact. diff --git a/calico-cloud_versioned_docs/version-20-1/image-assurance/creating-jira-issues-for-scan-results.mdx b/calico-cloud_versioned_docs/version-20-1/image-assurance/creating-jira-issues-for-scan-results.mdx deleted file mode 100644 index 8641fe0896..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/image-assurance/creating-jira-issues-for-scan-results.mdx +++ /dev/null @@ -1,38 +0,0 @@ ---- -description: Creating Jira Issues for you scan results. ---- - -import IconUser from '/img/icons/user-icon.svg'; - -# Create a Jira issue for your image scan results - -You can create and assign Jira issues with information about vulnerabilties from your Image Assurance scan results. - - -*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://
• `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 Calico Cloud Manager UI, go to **Image Assurance > Vulnerability Exceptions**, and then click
- 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_versioned_docs/version-20-1/image-assurance/scanners/pipeline-scanner.mdx b/calico-cloud_versioned_docs/version-20-1/image-assurance/scanners/pipeline-scanner.mdx deleted file mode 100644 index 8bd163f3b8..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/image-assurance/scanners/pipeline-scanner.mdx +++ /dev/null @@ -1,179 +0,0 @@ ---- -description: Scan images in your build pipeline using Image Assurance. ---- - -# Integrate the scanner into your build pipeline - -## 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 Manager UI. You can then use [Image Assurance Admission Controller](../install-the-admission-controller) to automatically blocks resources that would create containers with vulnerable images from entering your cluster. For a real-world use case, see [Hands-on guide: How to scan and block container images to mitigate SBOM attacks](https://www.tigera.io/blog/hands-on-guide-how-to-scan-and-block-container-images-to-mitigate-sbom-attacks/). - -## 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 Manager UI, 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 - - - -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
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. - - - -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) -- Create [policy](install-the-admission-controller.mdx) to block vulnerable containers from deploying to your cluster \ No newline at end of file diff --git a/calico-cloud_versioned_docs/version-20-1/multicluster/aws.mdx b/calico-cloud_versioned_docs/version-20-1/multicluster/aws.mdx deleted file mode 100644 index 631b562f86..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/multicluster/aws.mdx +++ /dev/null @@ -1,68 +0,0 @@ ---- -description: A sample configuration of Calico Enterprise federated endpoint identity and federated services for an AWS cluster. ---- - -# Cluster mesh example for clusters in AWS - -## Big picture - -A sample configuration for cluster mesh using AWS clusters. - -## Tutorial - -**Set up** - -The cluster is installed on real hardware where node and pod IPs are routable, using an edge VPN router to peer with the AWS cluster. - - - -**Calico Enterprise configuration** - -- IP pool resource is configured for the on-premise IP assignment with IPIP is disabled -- BGP peering to the VPN router -- A Remote Cluster Configuration resource references the AWS cluster -- Service discovery of the AWS cluster services uses the Calico Enterprise Federated Services Controller - -**Notes** - -- If VPN Router is configured as a route reflector for the on-premise cluster, you would: - - Configure the default BGP Configuration resource to disable node-to-node mesh - - Configure a global BGP Peer resource to peer with the VPN router -- If the IP Pool has `Outgoing NAT` enabled, then you must add an IP Pool covering the AWS cluster VPC with disabled set to `true`. When set to `true` the pool is not used for IP allocations, and SNAT is not performed for traffic to the AWS cluster. - -**AWS configuration** - -- A VPC CIDR is chosen that does not overlap with the on-premise IP ranges. -- There are 4 subnets within the VPC, split across two AZs (for availability) such that each AZ has a public and private subnet. In this particular example, the split of responsibility is: - - The private subnet is used for node and pod IP allocation - - The public subnet is used to home a NAT gateway for pod-to-internet traffic. -- The VPC is peered to an on-premise network using a VPN. This is configured as a VPN gateway for the AWS side, and a classic VPN for the customer side. BGP is used for route distribution. -- Routing table for private subnet has: - - "propagate" set to "true" to ensure BGP-learned routes are distributed - - Default route to the NAT gateway for public internet traffic - - Local VPC traffic -- Routing table for public subnet has default route to the internet gateway. -- Security group for the worker nodes has: - - Rule to allow traffic from the peered networks - - Other rules required for settings up VPN peering (refer to the AWS docs for details). - -To automatically create a Network Load Balancer (NLB) for the AWS deployment, we apply a service with the correct annotation. - -```yaml -apiVersion: v1 -kind: Service -metadata: - annotations: - service.beta.kubernetes.io/aws-load-balancer-type: nlb - name: nginx-external -spec: - externalTrafficPolicy: Local - ports: - - name: http - port: 80 - protocol: TCP - targetPort: 80 - selector: - run: nginx - type: LoadBalancer -``` diff --git a/calico-cloud_versioned_docs/version-20-1/multicluster/index.mdx b/calico-cloud_versioned_docs/version-20-1/multicluster/index.mdx deleted file mode 100644 index 50e8d21abf..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/multicluster/index.mdx +++ /dev/null @@ -1,19 +0,0 @@ ---- -description: Steps to configure cluster mesh. -hide_table_of_contents: true ---- - -import { DocCardLink, DocCardLinkLayout } from '/src/___new___/components'; - -# Cluster mesh - -With cluster mesh, you can secure cross-cluster connections using identity-aware network policy and federate services for cross-cluster service discovery. - -
Only services in the same namespace as the federated service are included. This implies namespace names across clusters are linked (this is a basic premise of federated endpoint identity).
If the value is incorrectly specified, the service is not federated and endpoint data is removed from the service. View the warning logs in the controller for any issues processing this value. | - -**Syntax and rules** - -- Services that you specify in the federated service must be in the same namespace or they are ignored. A basic assumption of federated endpoint identity is that namespace names are linked across clusters. -- If you specify a `spec.Selector` in a federated service, the service is not federated. -- You cannot federate another federated service. If a service has a federated services annotation, it is not included as a backing service of another federated service. -- The target port number in the federated service ports is not used. - -**Match services using a label** - -You can also match services using a label. The label is implicitly added to each service, but it does not appear in `kubectl` when viewing the service. - -| Label | Description | -| ---------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| `federation.tigera.io/remoteClusterName` | Label added to all remote services that correspond to the Remote Cluster Configuration name for the remote cluster. Use this label to restrict the clusters selected by the services. **Note**: The label is not added for services in the local cluster. | - -**About endpoints** - -- Do not manually create or manage endpoints resources; let the Tigera controller do all of the work. User updates to endpoint resources are ignored. -- Endpoints are selected only when the service port name and protocol in the federated service matches the port name and protocol in the backing service. -- Endpoint data configured in the federated service is slightly modified from the original data of the backing service. For backing services on remote clusters, the `targetRef.name` field in the federated service adds the `
- Staged network policy
Namespaced resources that apply only to workload endpoint resources in the namespace.
| -| `projectcalico.org/namespace` | Use only with selectors.
Use the label as the label name, and a namespace name as the value to compare against (for example projectcalico.org/namespace == "default"). | - Global network policy
- Staged global network policy
Cluster-wide (non-namespaced) resources that apply to workload endpoint resources in all namespaces, and to host endpoint resources. | diff --git a/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/calico-network-policy.mdx b/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/calico-network-policy.mdx deleted file mode 100644 index bd78699415..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/calico-network-policy.mdx +++ /dev/null @@ -1,256 +0,0 @@ ---- -description: Create your first Calico network policies. Shows the rich features using sample policies that extend native Kubernetes network policy. ---- - -# Get started with Calico network policy - -## Big picture - -Enforce which network traffic that is allowed or denied using rules in Calico network policy. - -## Value - -### Extends Kubernetes network policy - -Calico network policy provides a richer set of policy capabilities than Kubernetes including: policy ordering/priority, deny rules, and more flexible match rules. While Kubernetes network policy applies only to pods, Calico network policy can be applied to multiple types of endpoints including pods, VMs, and host interfaces. - -### Write once, works everywhere - -No matter which cloud provider you use now, adopting Calico network policy means you write the policy once and it is portable. If you move to a different cloud provider, you don’t need to rewrite your Calico network policy. Calico network policy is a key feature to avoid cloud provider lock-in. - -### Works seamlessly with Kubernetes network policies - -You can use Calico network policy in addition to Kubernetes network policy, or exclusively. For example, you could allow developers to define Kubernetes network policy for their microservices. For broader and higher-level access controls that developers cannot override, you could allow only security or Ops teams to define Calico network policies. - -## Concepts - -### Endpoints - -Calico network policies apply to **endpoints**. In Kubernetes, each pod is a Calico endpoint. However, Calico can support other kinds of endpoints. There are two types of Calico endpoints: **workload endpoints** (such as a Kubernetes pod or OpenStack VM) and **host endpoints** (an interface or group of interfaces on a host). - -### Namespaced and global network policies - -**Calico network policy** is a namespaced resource that applies to pods/containers/VMs in that namespace. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-port-6379 - namespace: production -``` - -**Calico global network policy** is a non-namespaced resource and can be applied to any kind of endpoint (pods, VMs, host interfaces) independent of namespace. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-tcp-port-6379 -``` - -Because global network policies use **kind: GlobalNetworkPolicy**, they are grouped separately from **kind: NetworkPolicy**. For example, global network policies will not be returned from `kubectl get networkpolicy.p`, and are rather returned from `kubectl get globalnetworkpolicy`. - -### Ingress and egress - -Each network policy rule applies to either **ingress** or **egress** traffic. From the point of view of an endpoint (pod, VM, host interface), **ingress** is incoming traffic to the endpoint, and **egress** is outgoing traffic from the endpoint. In a Calico network policy, you create ingress and egress rules independently (egress, ingress, or both). - -You can specify whether policy applies to ingress, egress, or both using the **types** field. If you do not use the types field, Calico defaults to the following values. - -| Ingress rule present? | Egress rule present? | Value | -| :-------------------: | :------------------: | :-------------: | -| No | No | Ingress | -| Yes | No | Ingress | -| No | Yes | Egress | -| Yes | Yes | Ingress, Egress | - -### Network traffic behaviors: deny and allow - -The Kubernetes network policy specification defines the following behavior: - -- If no network policies apply to a pod, then all traffic to/from that pod is allowed. -- If one or more network policies apply to a pod containing ingress rules, then only the ingress traffic specifically allowed by those policies is allowed. -- If one or more network policies apply to a pod containing egress rules, then only the egress traffic specifically allowed by those policies is allowed. - -For compatibility with Kubernetes, **Calico network policy** follows the same behavior for Kubernetes pods. For other endpoint types (VMs, host interfaces), Calico network policy is default deny. That is, only traffic specifically allowed by network policy is allowed, even if no network policies apply to the endpoint. - - - -## How to - -- [Control traffic to/from endpoints in a namespace](#control-traffic-tofrom-endpoints-in-a-namespace) -- [Control traffic to/from endpoints independent of namespace](#control-traffic-tofrom-endpoints-independent-of-namespace) -- [Control traffic to/from endpoints using IP addresses or CIDR ranges](#control-traffic-tofrom-endpoints-using-ip-addresses-or-cidr-ranges) -- [Apply network policies in specific order](#apply-network-policies-in-specific-order) -- [Generate logs for specific traffic](#generate-logs-for-specific-traffic) - -### Control traffic to/from endpoints in a namespace - -In the following example, ingress traffic to endpoints in the **namespace: production** with label **color: red** is allowed, only if it comes from a pod in the same namespace with **color: blue**, on port **6379**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-port-6379 - namespace: production -spec: - selector: color == 'red' - ingress: - - action: Allow - protocol: TCP - source: - selector: color == 'blue' - destination: - ports: - - 6379 -``` - -To allow ingress traffic from endpoints in other namespaces, use a **namespaceSelector** in the policy rule. A namespaceSelector matches namespaces based on the labels that are applied in the namespace. In the following example, ingress traffic is allowed from endpoints in namespaces that match **shape == circle**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-port-6379 - namespace: production -spec: - selector: color == 'red' - ingress: - - action: Allow - protocol: TCP - source: - selector: color == 'blue' - namespaceSelector: shape == 'circle' - destination: - ports: - - 6379 -``` - -### Control traffic to/from endpoints independent of namespace - -The following Calico network policy is similar to the previous example, but uses **kind: GlobalNetworkPolicy** so it applies to all endpoints, regardless of namespace. - -In the following example, incoming TCP traffic to any pods with label **color: red** is denied if it comes from a pod with **color: blue**. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: deny-blue -spec: - selector: color == 'red' - ingress: - - action: Deny - protocol: TCP - source: - selector: color == 'blue' -``` - -As with **kind: NetworkPolicy**, you can allow or deny ingress traffic from endpoints in specific namespaces using a namespaceSelector in the policy rule: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: deny-circle-blue -spec: - selector: color == 'red' - ingress: - - action: Deny - protocol: TCP - source: - selector: color == 'blue' - namespaceSelector: shape == 'circle' -``` - -### Control traffic to/from endpoints using IP addresses or CIDR ranges - -Instead of using a selector to define which traffic is allowed to/from the endpoints in a network policy, you can also specify an IP block in CIDR notation. - -In the following example, outgoing traffic is allowed from pods with the label **color: red** if it goes to an IP address in the **1.2.3.4/24** CIDR block. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-egress-external - namespace: production -spec: - selector: color == 'red' - types: - - Egress - egress: - - action: Deny - destination: - nets: - - 1.2.3.0/24 -``` - -### Apply network policies in specific order - -To control the order/sequence of applying network policies, you can use the **order** field (with precedence from the lowest value to highest). Defining policy **order** is important when you include both **action: allow** and **action: deny** rules that may apply to the same endpoint. - -In the following example, the policy **allow-cluster-internal-ingress** (order: 10) will be applied before the **policy drop-other-ingress** (order: 20). - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: drop-other-ingress -spec: - order: 20 - #...deny policy rules here... -``` - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-cluster-internal-ingress -spec: - order: 10 - #...allow policy rules here... -``` - -### Generate logs for specific traffic - -In the following example, incoming TCP traffic to an application is denied, and each connection attempt is logged to syslog. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: allow-tcp-port-6379 - namespace: production -spec: - selector: role == 'database' - types: - - Ingress - - Egress - ingress: - - action: Log - protocol: TCP - source: - selector: role == 'frontend' - - action: Deny - protocol: TCP - source: - selector: role == 'frontend' -``` - -### Create policy for established connections - -Policies are immediately applied to any new connections. However, for existing connections that are already open, the policy changes will only take effect after the connection has been reestablished. This means that any ongoing sessions may not immediately reflect policy changes until they are initiated again. - -## Additional resources - -- For additional Calico network policy features, see [Calico network policy](../../reference/resources/networkpolicy.mdx) and [Calico global network policy](../../reference/resources/globalnetworkpolicy.mdx) -- For an alternative to using IP addresses or CIDRs in policy, see [Network sets](../../reference/resources/networkset.mdx) -- For details on how to stage network policy, see [Staged network policies](../staged-network-policies.mdx) diff --git a/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/index.mdx b/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/index.mdx deleted file mode 100644 index 1b7a16054f..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Learn how to create your first Calico Cloud network policy. -hide_table_of_contents: true ---- - -# Calico Cloud network policy for beginners - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - -
Possible unnecessary network hops between nodes for ingress external traffic.When packets are rerouted to pods on another node, traffic is SNAT’d (source network address translation).
Destination pod can see the proxying node’s IP address rather than the actual client IP. | **ClusterIP** | -| **externalTrafficPolicy: Local** | Across the nodes with the endpoints for the service | Avoids extra hops so better for apps that ingress a lot external traffic.
Traffic is not SNAT’d so actual client IPs are preserved.
Traffic distributed among pods running a service may be imbalanced. | **LoadBalancer** (for cloud providers), or **NodePort** (for node’s static port) | - -## Before you begin... - -[Configure Calico to advertise cluster IPs over BGP](../../../networking/configuring/advertise-service-ips.mdx). - -## How to - -Selecting which mode to use depends on your goals and resources. At an operational level, **local mode** simplifies policy, but load balancing may be uneven in certain scenarios. **Cluster mode** requires more work to manage clusterIPs, SNAT, and create policies that reference specific IP addresses, but you always get even load balancing. - -- [Secure externally exposed cluster IPs, local mode](#secure-externally-exposed-cluster-ips-local-mode) -- [Secure externally exposed cluster IPs, cluster mode](#secure-externally-exposed-cluster-ips-cluster-mode) - -### Secure externally exposed cluster IPs, local mode - -Using **local mode**, the original source address of external traffic is preserved, and you can define policy directly using standard $[prodname] network policy. - -1. Create $[prodname] **NetworkPolicies** or **GlobalNetworkPolicies** that select the same set of pods as your Kubernetes Service. -1. Add rules to allow the external traffic. -1. If desired, add rules to allow in-cluster traffic. - -### Secure externally exposed cluster IPs, cluster mode - -In the following steps, we define **GlobalNetworkPolicy** and **HostEndpoints**. - -#### Step 1: Verify Kubernetes Service manifest - -Ensure that your Kubernetes Service manifest explicitly lists the clusterIP; do not allow Kubernetes to automatically assign the clusterIP because you need it for your policies in the following steps. - -#### Step 2: Create global network policy at the host interface - -In this step, you create a **GlobalNetworkPolicy** that selects all **host endpoints**. It controls access to the cluster IP, and prevents unauthorized clients from outside the cluster from accessing it. The hosts then forwards only authorized traffic. - -**Set policy to allow external traffic for cluster IPs** - -Add rules to allow the external traffic for each clusterIP. The following example allows connections to two cluster IPs. Make sure you add **applyOnForward** and **preDNAT** rules. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-cluster-ips -spec: - selector: k8s-role == 'node' - types: - - Ingress - applyOnForward: true - preDNAT: true - ingress: - # Allow 50.60.0.0/16 to access Cluster IP A - - action: Allow - source: - nets: - - 50.60.0.0/16 - destination: - nets: - - 10.20.30.40/32 Cluster IP A - # Allow 70.80.90.0/24 to access Cluster IP B - - action: Allow - source: - nets: - - 70.80.90.0/24 - destination: - nets: - - 10.20.30.41/32 Cluster IP B -``` - -**Add a rule to allow traffic destined for the pod CIDR** - -Without this rule, normal pod-to-pod traffic is blocked because the policy applies to forwarded traffic. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-to-pods -spec: - selector: k8s-role == 'node' - types: - - Ingress - applyOnForward: true - preDNAT: true - ingress: - # Allow traffic forwarded to pods - - action: Allow - destination: - nets: - - 192.168.0.0/16 Pod CIDR -``` - -**Add a rule to allow traffic destined for all host endpoints** - -Or, you can add rules that allow specific host traffic including Kubernetes and $[prodname]. Without this rule, normal host traffic is blocked. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-traffic-hostendpoints -spec: - selector: k8s-role == 'node' - types: - - Ingress - # Allow traffic to the node (not nodePorts, TCP) (not nodePorts, TCP) - - action: Allow - protocol: TCP - destination: - selector: k8s-role == 'node' - notPorts: ["30000:32767"] #nodePort range - # Allow traffic to the node (not nodePorts, TCP) (not nodePorts, UDP) - - action: Allow - protocol: UDP - destination: - selector: k8s-role == 'node' - notPorts: ["30000:32767"] #nodePort range -``` - -#### Step 3: Create a global network policy that selects pods - -In this step, you create a **GlobalNetworkPolicy** that selects the **same set of pods as your Kubernetes Service**. Add rules that allow host endpoints to access the service ports. - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalNetworkPolicy -metadata: - name: allow-nodes-svc-a -spec: - selector: k8s-svc == 'svc-a' - types: - - Ingress - ingress: - - action: Allow - protocol: TCP - source: - selector: k8s-role == 'node' - destination: - ports: [80, 443] - - action: Allow - protocol: UDP - source: - selector: k8s-role == 'node' - destination: - ports: [80, 443] -``` - -#### Step 4: (Optional) Create network polices or global network policies that allow in-cluster traffic to access the service - -#### Step 5: Create HostEndpoints - -Create HostEndpoints for the interface of each host that will receive traffic for the clusterIPs. Be sure to label them so they are selected by the policy in Step 2 (Add a rule to allow traffic destined for the pod CIDR), and the rules in Step 3. - -In the previous example policies, the label **k8s-role: node** is used to identify these HostEndpoints. - -## Additional resources - -- [Enable service IP advertisement](../../../networking/configuring/advertise-service-ips.mdx) -- [Defend against DoS attacks](../../extreme-traffic/defend-dos-attack.mdx) -- [Global network policy](../../../reference/resources/globalnetworkpolicy.mdx) diff --git a/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/simple-policy-cnx.mdx b/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/simple-policy-cnx.mdx deleted file mode 100644 index cee56954e0..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/network-policy/beginners/simple-policy-cnx.mdx +++ /dev/null @@ -1,331 +0,0 @@ ---- -description: Learn the extra features for Calico Cloud that make it so important for production environments. ---- - -# Calico Cloud for Kubernetes demo - -This guide is a variation of the [simple policy demo](../../tutorials/kubernetes-tutorials/kubernetes-policy-basic.mdx) intended to introduce the extra features of $[prodname] to people already familiar with Project Calico for Kubernetes. - -It requires a Kubernetes cluster configured with Calico networking and $[prodname], and expects that you have `kubectl` configured to interact with the cluster. - - - -This guide assumes that you have installed all the $[prodname] components from the -guides above and that your cluster consists of the following nodes: - -- k8s-node1 -- k8s-node2 -- k8s-master - -Where you see references to these in the text below, substitute for your actual node names. You can find what nodes are on your cluster with `kubectl get nodes` - -## Configure Namespaces - -This guide will deploy pods in a Kubernetes namespace. Let's create the `Namespace` object for this guide. - -``` -kubectl create ns policy-demo -``` - -## Create demo pods - -We'll use Kubernetes `Deployment` objects to easily create pods in the namespace. - -1. Create some nginx pods in the `policy-demo` namespace. - - ```shell - kubectl create deployment --namespace=policy-demo nginx --image=nginx - ``` - -1. Expose them through a service. - - ```shell - kubectl expose --namespace=policy-demo deployment nginx --port=80 - ``` - -1. Ensure the nginx service is accessible. - - ```shell - kubectl run --namespace=policy-demo access --rm -ti --image busybox /bin/sh - ``` - - This should open up a shell session inside the `access` pod, as shown below. - - ``` - Waiting for pod policy-demo/access-472357175-y0m47 to be running, status is Pending, pod ready: false - - If you don't see a command prompt, try pressing enter. - - / # - ``` - -1. From inside the `access` pod, attempt to reach the `nginx` service. - - ```shell - wget -q nginx -O - - ``` - - You should see a response from `nginx`. Great! Our service is accessible. You can exit the pod now. - -1. Inspect the network policies using calicoq. The `host` command displays - information about the policies for endpoints on a given host. - - :::note - - calicoq complements calicoctl by inspecting the - dynamic aspects of $[prodname] Policy: in particular displaying the endpoints actually affected by policies, - and the policies that actually apply to endpoints. - - - ::: - - ``` - DATASTORE_TYPE=kubernetes calicoq host k8s-node1 - ``` - - You should see the following output. - - ``` - Policies and profiles for each endpoint on host "k8s-node1": - - Workload endpoint k8s/tigera-prometheus.alertmanager-calico-node-alertmanager-0/eth0 - Policies: - Policy "tigera-prometheus/knp.default.calico-node-alertmanager" (order 1000; selector "(projectcalico.org/orchestrator == 'k8s' && alertmanager == 'calico-node-alertmanager' && app == 'alertmanager') && projectcalico.org/namespace == 'tigera-prometheus'") - Policy "tigera-prometheus/knp.default.calico-node-alertmanager-mesh" (order 1000; selector "(projectcalico.org/orchestrator == 'k8s' && alertmanager == 'calico-node-alertmanager' && app == 'alertmanager') && projectcalico.org/namespace == 'tigera-prometheus'") - Policy "tigera-prometheus/knp.default.default-deny" (order 1000; selector "(projectcalico.org/orchestrator == 'k8s') && projectcalico.org/namespace == 'tigera-prometheus'") - Profiles: - Profile "kns.tigera-prometheus" - Rule matches: - Policy "tigera-prometheus/knp.default.calico-node-alertmanager-mesh" inbound rule 1 source match; selector "(projectcalico.org/namespace == 'tigera-prometheus') && (projectcalico.org/orchestrator == 'k8s' && app in { 'alertmanager' } && alertmanager in { 'calico-node-alertmanager' })" - - ... - - Workload endpoint k8s/policy-demo.nginx-8586cf59-5bxvh/eth0 - Policies: - Profiles: - Profile "kns.policy-demo" - ``` - - For each workload endpoint, the `Policies:` section lists the policies that - apply to that endpoint, in the order they apply. calicoq displays both - $[prodname] Policies and Kubernetes NetworkPolicies, although this - example focuses on the latter. The `Rule matches:` section lists the - policies that match that endpoint in their rules, in other words that have - rules that deny or allow that endpoint as a packet source or destination. - - Focusing on the - `k8s/tigera-prometheus.alertmanager-calico-node-alertmanager-0/eth0` endpoint: - - - The first two policies are defined in the monitor-calico.yaml manifest. - The selectors here have been translated from the original NetworkPolicies to - the $[prodname] format (note the addition of the namespace test). - - - The third policy and the following profile are created automatically by the - policy controller. - -1. Use kubectl to see the detail of any particular policy or profile. For - example, for the `kns.policy-demo` profile, which defines default behavior for - pods in the `policy-demo` namespace: - - ```shell - kubectl get profile kns.policy-demo -o yaml - ``` - - You should see the following output. - - ```yaml - apiVersion: projectcalico.org/v3 - kind: Profile - metadata: - creationTimestamp: '2022-01-06T21:32:05Z' - name: kns.policy-demo - resourceVersion: 435026/ - uid: 75dd2ed4-d3a6-41ca-a106-db073bfa946a - spec: - egress: - - action: Allow - destination: {} - source: {} - ingress: - - action: Allow - destination: {} - source: {} - labelsToApply: - pcns.projectcalico.org/name: policy-demo - ``` - - Alternatively, you may also use $[prodname] Manager to inspect and view information and metrics associated with policies, endpoints, and nodes. - -## Enable isolation - -Let's turn on isolation in our policy-demo namespace. $[prodname] will then prevent connections to pods in this namespace. - -Running the following command creates a NetworkPolicy which implements a default deny behavior for all pods in the `policy-demo` namespace. - -```shell -kubectl create -f - <
**-** 1 iptables/eBPF rule
- 1 IP set with handful of CIDRs | -| source: nets: [ ... handful ...] | Not used | **Efficient**
- Handful of iptables/eBPF rules
- 0 IP sets | -| source: selector: foo="bar" | One network set with 2000 x /32s | **`*`Most efficient**
- 1 iptables/eBPF rule
- 1 IP sets with 2000 entries | -| | Two network sets with 1000 each x /32s | **Efficient**
- 2 iptables/eBPF rules
- 2 IP set with 1000 entries | -| source:
nets: [... 2000 /32s ...]
- source:
nets: [1 x /32]
- source: nets: [1 x /32]
- ... x 2000 | Not used | **Inefficient**
Results in programming 2k iptables/eBPF rules
- 2000+ iptables/eBPF rules
- 0 IP sets | - -`*` Updating **ipsets** is fast and efficient. Adding/removing a single entry is an O(1) operation no matter the number of IPs in the set. Updating **iptables** is generally slow and gets slower the more rules you have in total (including rules created by kube-proxy, for example). Less than 10K rules are generally fine, but noticeable latency occurs when updating rules above that number (increasing as the number of rules grows). (The newer nftables may scale more efficiently but those results are not included here.) - -Similarly, hitting many iptables (or eBPF) rules adds latency to the first packet in a flow. For iptables, it measures around 250ns per rule. Although a single rule is negligible, hitting 10K rules add >1ms to the first packet in the flow. Packets only hit the rules for the particular interface that they arrive on; if you have 10K rules on one interface and 10 rules on another, the packet processed by the first interface will have more latency. - -## Additional resources - -- [Network set](../reference/resources/networkset.mdx) -- [Global network set](../reference/resources/globalnetworkset.mdx) diff --git a/calico-cloud_versioned_docs/version-20-1/network-policy/policy-best-practices.mdx b/calico-cloud_versioned_docs/version-20-1/network-policy/policy-best-practices.mdx deleted file mode 100644 index 5dfc74f2e9..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/network-policy/policy-best-practices.mdx +++ /dev/null @@ -1,355 +0,0 @@ ---- -description: Learn policy best practices for security, scalability, and performance. ---- - -# Policy best practices - -## Big picture - -Policy best practices for run-time security starts with $[prodname]’s robust network security policy, but other $[prodname] resources play equally important roles in security, scalability, and performance. - -Learn $[prodname] policy best practices and resources that support a zero trust network model: - -- [Prepare for policy authoring](#prepare-for-policy-authoring) -- [Policy best practices for day-one zero trust](#policy-best-practices-for-day-one-zero-trust) -- [Policy design for efficiency and performance](#policy-design-for-efficiency-and-performance) -- [Policy life cycle tools](#policy-life-cycle-tools) - -## Prepare for policy authoring - -### Determine who can write policy - -Any team familiar with deploying microservices in Kubernetes can easily master writing network policies. The challenge in many organizations is deciding who will be given permission to write policy across teams. Although there are different approaches, $[prodname] policy tools have the flexibility and guardrails to accommodate different approaches. - -Let’s review two common approaches. - -- **Microservices teams write policy** - - In this model, network policy is treated as code, built into and tested during the development process, just like any other critical part of a microservice’s code. The team responsible for developing a microservice has a good understanding of other microservices they consume and depend on, and which microservices consume their microservice. With a defined, standardized approach to policy and label schemas, there is no reason that the teams cannot implement network policies for their microservice as part of the development of the microservice. With visibility in Service Graph, teams can even do basic troubleshooting. - -- **Dev/Ops writes policy, microservice team focuses on internals** - An equally valid approach is to have development teams focus purely on the internals of the microservices they are responsible for, and leave responsibility for operating the microservices with devops teams. A Dev/ops team needs the same understanding as the microservices team above. However, network security may come much later in the organization’s processes, or even as an afterthought on a system already in production. This can be more challenging because getting network policies wrong can have significant production impacts. But using $[prodname] tools, this approach is still achievable. - -When you get clarity on who can write policies, you can move to creating tiers. $[prodname] tiers, along with standard Kubernetes RBAC, provide the infrastructure to meet security concerns across teams. - -### Understand the depth of $[prodname] network policy - -Because $[prodname] policy goes well beyond the features in Kubernetes policy, we recommend that you have a basic understanding of [network policy and global network policy](beginners/calico-network-policy.mdx) and how they provide workload access controls. And even though you may not implement the following policies, it is helpful to know the depth of defense that is available in $[prodname]. - -- [Policy for services](beginners/services/index.mdx) -- [Policy integration for firewalls](policy-firewalls/index.mdx) - -### Create policy tiers - -**Tiers** are a hierarchical construct used to group policies and enforce higher precedence policies that cannot be circumvented by other teams. As part of your microsegmentation strategy, tiers let you apply identity-based protection to workloads and hosts. - -Before creating policies, we recommend that you create your tier structure. This often requires internal debates and discussions. As noted previously, $[prodname] policy workflow has the guardrails you need to allow diverse teams to participate in policy writing. - -To understand how tiered policy works and best practices, see [Get started with tiered policies](policy-tiers/tiered-policy.mdx). - -### Create label standards - -Creating a label standard is often an overlooked step. But if you skip this step, it will cost you in troubleshooting down the road; especially given visibility/troubleshooting is already a challenge in a Kubernetes deployment. - -**Why are label standards important?** - -Network policies in Kubernetes depend on **labels and selectors** (not IP addresses and IP ranges) to determine which workloads can talk to each other. As pods dynamically scale up and down, network policy is enforced based on the labels and selectors that you define. So workloads and host endpoints need unique, identifiable labels. If you create duplicate label names, or labels are not intuitive, troubleshooting network policy issues and authoring network policies becomes more difficult. - -**Recommendations**: - -- Follow the [Kubernetes guidelines for labels](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/). If the Kubernetes guidelines do not cover your use cases, we recommend this blog from Tigera Support: [Label standard and best practices for Kubernetes security](https://www.helpnetsecurity.com/2021/05/26/kubernetes-security/). -- Develop a comprehensive set of labels that meets the deployment, reporting, and security requirements of different stakeholders in your organization. -- Standardize the way you label your pods and write your network policies using a consistent schema or design pattern. -- Labels should be defined to achieve a specific and explicit purpose -- Use an intuitive language in your label definition that enables a quick and simple identification of labeled Kubernetes objects. -- Use label key prefixes and suffixes to identify attributes required for asset classification. -- Ensure the right labels are applied to Kubernetes objects by implementing label governance checks in your CI/CD pipeline or at runtime. - -### Create network sets - -Network sets and global network sets are grouping mechanisms for arbitrary sets of IPs/subnets/CIDRs or domains. They are key resources for efficient policy design. The key use cases for network sets are: - -- **Use/reuse in policy to support scaling** - - You reference network sets in policies using selectors (rather than updating individual policies with CIDRs or domains). - -- **Visibility to traffic to/from a cluster** - - For apps that integrate with third-party APIs and SaaS services, you get enhanced visibility to this traffic in Service Graph. - -- **Global deny lists** - - Create a “deny-list” of CIDRs for bad actors or embargoed countries in policy. - -**Recommendation**: Create network sets **and labels** before writing policy. - -For network set tutorial and best practices, see [Get started with network sets](networksets.mdx). - -## Policy best practices for day-one zero trust - -### Create a global default deny policy - -A global default deny network policy provides an enhanced security posture – so pods without policy (or incorrect policy) are not allowed traffic until appropriate network policy is defined. We recommend creating a global default deny, regardless of whether you use Calico Enterprise and/or Kubernetes network policy. - -But, be sure to understand the [best practices for creating a default deny policy](default-deny.mdx) to avoid breaking your cluster. - -Here are sample [default deny policies](beginners/kubernetes-default-deny.mdx). - -### Define both ingress and egress network policy rules for every pod in the cluster - -Although defining network policy for traffic external to clusters (north-south) is certainly important, it is equally important to defend against attacks for east-west traffic. Simply put, **every connection from/to every pod in every cluster should be protected**. Although having both doesn’t guarantee protection against other attacks and vulnerabilities, one innocuous workload can lead to exposure of your most critical workloads. - -For examples, see [basic ingress and egress policies](beginners/calico-network-policy.mdx). - -## Policy design for efficiency and performance - -Teams can write policies that work, but ultimately you want policies that also scale, and do not negatively impact performance. - -If you follow a few simple guidelines, you’ll be well on your way to writing efficient policy. - -### Use global network policy only when all rules apply globally - -- **Do** - - Use global network policy for cluster-wide scope when all rules apply to multiple namespaces or host endpoints. For example, use a global network policy to create a deny-list of CIDRs for embargoed countries, or for global default deny everywhere, even for new namespaces. - - Why? Although at the level of packet processing there is no difference between network policy and global network, for CPU usage, one global network policy is faster than a large number of network policies. - -- **Avoid** - - Using a global network policy as a way to combine diverse, namespaced endpoints with different connectivity requirements. Although creating such a policy can work, appears efficient and is easier to view than several separate network policies, it is inefficient and should be avoided. - - Why? Putting a lot of anything in policy (rules, CIDRs, ports) that are manipulated by selectors is inefficient. iptables/eBPF rules depend on minimizing executions and updates. When a selector is encountered in a policy rule, it is converted into one iptables rule that matches on an IP set. Then, different code keeps the IP sets up to date; this is more efficient than updating iptables rules. Also, because iptables rules execute sequentially in order, having many rules results in longer network latencies for the first packet in a flow (approximately 0.25-0.5us per rule). Finally, having more rules slows down programming of the dataplane, making policy updates take longer. - -**Example: Inefficient global network policy** - -The following policy is a global network policy for a microservice that limits all egress communication external to the cluster in the security tier. Does this policy work? Yes. And logically, it seems to cleanly implement application controls. - -```yaml noValidation -1 apiVersion: projectcalico.org/v3 -2 kind: GlobalNetworkPolicy -3 metadata: -4 name: security.allow-egress-from-pods -5 spec: -6 tier: security -7 order: 1 -8 selector: all() -9 egress: -10 - action: Deny -11 source: -12 namespaceSelector: projectcalico.org/namespace starts with "tigera" -13 destination: -14 selector: threatfeed == "feodo" -15 - action: Allow -16 protocol: TCP -17 source: -18 namespaceSelector: projectcalico.org/name == "sso" -19 ports: -20 - '443' -21 - '80' -22 destination: -23 domains: -24 - '*.googleapis.com' -25 - action: Allow -26 protocol: TCP -27 source: -28 selector: psql == "external" -29 destination: -30 ports: -31 - '5432' -32 domains: -33 - '*.postgres.database.azure.com' -34 - action: Allow -35 protocol: TCP -36 source: {} -37 destination: -38 ports: -39 - '443' -40 - '80' -41 domains: -42 - '*.logic.azure.com' -43 - action: Allow -44 protocol: TCP -45 source: {} -46 destination: -47 ports: -48 - '443' -49 - '80' -50 domains: -51 - '*.azurewebsites.windows.net' -52 - action: Allow -53 protocol: TCP -54 source: -55 selector: 'app in { "call-archives-api" }||app in { "finwise" }' -56 destination: -57 domains: -58 - '*.documents.azure.com' -59 - action: Allow -60 protocol: TCP -61 source: -62 namespaceSelector: projectcalico.org/name == "warehouse" -63 destination: -64 ports: -65 - '1433' -66 domains: -67 - '*.database.windows.net' -68 - action: Allow -69 protocol: TCP -70 source: {} -71 destination: -72 nets: -73 - 65.132.216.26/32 -74. - 10.10.10.1/32 -75 ports: -76 - '80' -77 - '443' -78 - action: Allow -79 protocol: TCP -80 source: -81 selector: app == "api-caller" -82 destination: -83 ports: -84 - '80' -85 - '443' -86 domains: -87 - api.example.com -88 - action: Allow -89 source: -90 selector: component == "tunnel" -91 - action: Allow -92 destination: -93 selector: all() -94 namespaceSelector: all() -95 - action: Deny -96 types: -97 - Egress -``` - -**Why this policy is inefficient** - -First, the policy does not follow guidance on use for global network policy: that all rules apply to the endpoints. So the main issue is inefficiency, although the policy works. - -The main selector `all()` (line 8) means the policy will be rendered on every endpoint (workload and host endpoints). The selectors in each rule (for example, lines 12 and 14) control traffic that are matched by that rule. So, even if the host doesn’t have any workloads that match `"selector: app == "api-caller"`, you’ll still get the iptables/eBPF rule rendered on every host to implement that rule. If this sample policy had 100 pods, that’s a 10 - 100x increase in the number of rules (depending on how many local endpoints match each rule). In short, it adds: - -- Memory and CPU to keep track of all the extra rules -- Complexity to handle changes to endpoint labels, and to re-render all the policies too. - -### Avoid policies that may select unwanted endpoints - -The following policy is for an application in a single namespace, `app1-ns` namespace. There are two microservices that are all labeled appropriately: - -- microservice 1 has `app: app1`, `svc: svc1` -- microservice 2 has `app: app1`, `svc: svc2` - -The following policy works correctly and does not incur a huge performance hit. But it could select additional endpoints that were not intended. - -```yaml -apiVersion: projectcalico.org/v3 -kind: NetworkPolicy -metadata: - name: application.app1 - namespace: app1-ns -spec: - tier: application - order: 10 - selector: app == "app1" - types: - - Ingress - ingress: - - action: Allow - source: - selector: trusted-ip == "load-balancer" - destination: - selector: svc == "svc1" - ports: - - 10001 - protocol: TCP - - action: Allow - source: - selector: svc == "svc1" - destination: - selector: svc == "svc2" - ports: - - 10002 - protocol: TCP -``` - -The policy incorrectly assumes that the main policy selector (`app == "app1"`) will be combined (ANDed) with the endpoint selector, and only for certain policy types. In this case, - -- **Ingress** - combines policy selector and _destination endpoint selector_ - or -- **Egress** - combines policy selector and _source endpoint selector_ - -But if the assumptions behind the labels are not understood by other policy authors and are not correctly assigned, the endpoint selector may select _additional endpoints that were not intended_. For ingress policy, this can open up the endpoint to more IP addresses than necessary. This unintended consequence would be exacerbated if the author used a global network policy. - -### Put multiple relevant policy rules together in the same policy - -As discussed previously, it is better to create separate policies for different endpoint connectivity rules, than a single global network policy. However, you may interpret this to mean that the best practice is to make unique policies that do not aggregate any rules. But that is not the case. Why? When $[prodname] calculates and enforces policy, it updates the iptables/eBPF and reads policy changes and pod/workload endpoints from the datastore. The more policies in memory, the more work it takes determine which policies match a particular endpoint. If you group more rules into one policy, there are fewer policies to match against. - -### Understand effective use of label selectors - -Label selectors abstract network policy from the network. Misuse of selectors can slow things down. As discussed previously, the more selectors you create, the harder $[prodname] works to find matches. - -The following policy shows an inefficient use of selectors. Using `selector: all()` renders the policy on all nodes for all workloads. If there are 10,000 workloads, but only 10 match label==foo, that is very inefficient at the dataplane level. - -```yaml -selector: all() -ingress: - - source: - selector: label == 'bar' - destination: - selector: label == 'foo' -``` - -The best practice policy below allows the same traffic, but is more efficient and scalable. Why? Because the policy will be rendered only on nodes with workloads that match the selector `label==foo`. - -```yaml -selector: label == 'foo' -ingress: - source: - selector: label == 'bar' -``` - -Another common mistake is using `selector: all()` when you don’t need to. `all()` means _all workloads_ so that will be a large IP set. Whenever there's a source/destination selector in a rule, it is rendered as an IP set in the dataplane. - -```yaml -source: - selector: all() -``` - -### Put domains and CIDRs in network sets rather than policy - -Network sets allow you to specify CIDRs and/or domains. As noted in [Network set best practices](policy-best-practices.mdx), we do not recommend putting large CIDRs or domains directly in policy. Although nothing stops you from do this in policy, using network sets is more efficient and supports scaling. - -## Policy life cycle tools - -### Preview, stage, deploy - -A big obstacle to adopting Kubernetes is not having confidence that you can effectively prevent, detect, and mitigate across diverse teams. The following policy life cycle tools in Manager UI (**Policies** tab) can help. - -- **Policy recommendations** - - Get a policy recommendation for unprotected workloads. Speeds up learning, while supporting zero trust. - -- **Policy impact preview** - - Preview the impacts of policy changes before you apply them to avoid unintentionally exposing or blocking other network traffic. - -- **Policy staging and audit modes** - - Stage network policy so you can monitor traffic impact of both Kubernetes and $[prodname] policy as if it were actually enforced, but without changing traffic flow. This minimizes misconfiguration and potential network disruption. - -For details, see [Policy life cycle tools](staged-network-policies.mdx). - -### Do not trust anything - -Zero trust means that you do not trust anyone or anything. $[prodname] handles authentication on a per request basis. Every action is either authorized or restricted, and the default is everything is restricted. To apply zero trust to policy and reduce your attack surface and risk, we recommend the following: - -- Ensure that all expected and allowed network flows are explicitly allowed; any connection not explicitly allowed is denied - -- Create a quarantine policy that denies all traffic that you can quickly apply to workloads when you detect suspicious activity or threats - -## Additional resources - -- [Troubleshoot policies](policy-troubleshooting.mdx) -- [Security and policy best practices blog](https://www.tigera.io/blog/kubernetes-security-policy-10-critical-best-practices/) diff --git a/calico-cloud_versioned_docs/version-20-1/network-policy/policy-firewalls/fortinet-integration/firewall-integration.mdx b/calico-cloud_versioned_docs/version-20-1/network-policy/policy-firewalls/fortinet-integration/firewall-integration.mdx deleted file mode 100644 index ba0cfbf1c7..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/network-policy/policy-firewalls/fortinet-integration/firewall-integration.mdx +++ /dev/null @@ -1,244 +0,0 @@ ---- -description: Enable FortiGate firewalls to control traffic from Kubernetes workloads. ---- - -# Extend Kubernetes to Fortinet firewall devices - -## Big picture - -Use $[prodname] network policy to control traffic from Kubernetes clusters in your FortiGate firewalls. - -## Value - -As platform and security engineers, you want your apps to securely communicate with the external world. But you also want to secure the network traffic from the Kubernetes clusters using your Fortigate firewalls. Using the Fortinet/$[prodname] integration, security teams can retain firewall responsibility, secure traffic using $[prodname] network policy, which frees up time for ITOps. - -## Concepts - -## Integration at a glance - -This $[prodname]/Fortinet integration workflow lets you control egress traffic leaving the Kubernetes cluster. You create perimeter firewall policies in FortiManager and FortiGate that reference Kubernetes workloads. $[prodname] acts as a conduit, using the `tigera-firewall-controller` and global network policies to pass Kubernetes workload information to FortiManager and Fortigate devices where policies are applied and enforced. - -The basic workflow is: - -1. Determine the Kubernetes pods that are allowed access outside the perimeter firewall. -1. Create $[prodname] global network policies with selectors that match those pods. Each global network policy maps to an address group in the FortiGate firewall. -1. Deploy the `tigera firewall controller` in the Kubernetes cluster. -1. Create a ConfigMap with Fortinet firewall information. - The `tigera firewall controller` reads the ConfigMap, gets the FortiGate firewall IP address, API token, and source IP address selection with `node` or `pod`. In your Kubernetes cluster, the controller populates pod IPs or Kubernetes node IPs of selector matching pods in Fortigate address group objects. - -## Before you begin - -**Supported versions** - -- FortiGate v6.2 -- FortiManager v6.4 - -**Required** - - -- IPv4 CIDR’s or IP addresses of all Kubernetes nodes; this is required for FortiManager to treat Kubernetes nodes as trusted hosts. - -**Recommended** - -- Experience creating and administering FortiGate/FortiManager firewall policies -- Experience using [$[prodname] tiers](../../../reference/resources/tier.mdx) and [Global network policy](../../../reference/resources/globalnetworkpolicy.mdx) - -## How to - -- [Create tier and global network policy](#create-tier-and-global-network-policy) -- [Configure FortiGate firewall to communicate with firewall controller](#configure-fortigate-firewall-to-communicate-with-firewall-controller) -- [Configure FortiManager to communicate with firewall controller](#configure-fortimanager-to-communicate-with-firewall-controller) -- [Create a config map for address selection in firewall controller](#create-a-config-map-for-address-selection-in-firewall-controller) -- [Create a config map with FortiGate and FortiManager information](#create-a-config-map-with-fortigate-and-fortimanager-information) -- [Install FortiGate ApiKey and FortiManager password as secrets](#install-fortigate-apikey-and-fortimanager-password-as-secrets) -- [Deploy firewall controller in the Kubernetes cluster](#deploy-firewall-controller-in-the-kubernetes-cluster) - -### Create tier and global network policy - -1. Create a tier for organizing global network policies. - - Create a new [Tier](../../policy-tiers/tiered-policy.mdx) to organize all Fortigate firewall global network policies in a single location. - -1. Note the tier name to use in a later step for the FortiGate firewall information config map. - -1. Create a GlobalNetworkPolicy for address group mappings. - - For example, a GlobalNetworkPolicy can select a set of pods that require egress access to external workloads. In the following GlobalNetworkPolicy, the firewall controller creates an address group named, `default.production-microservice1` in the Fortigate firewall. The members of `default.production-microservice1` address group include IP addresses of nodes. Each node can host one or more pods whose label selector match with `env == 'prod' && role == 'microservice1'`. Each GlobalNetworkPolicy maps to an address group in FortiGate firewall. - - ```yaml - apiVersion: projectcalico.org/v3 - kind: GlobalNetworkPolicy - metadata: - name: default.production-microservice1 - spec: - selector: "env == 'prod' && role == 'microservice1'" - types: - - Egress - egress: - - action: Allow - ``` - -### Configure FortiGate firewall to communicate with firewall controller - -1. Determine and note the CIDR's or IP addresses of all Kubernetes nodes that can run the `tigera-firewall-controller`. - Required to explicitly allow the `tigera-firewall-controller` to access the FortiGate API. -1. Create an Admin profile with read-write access to Address and Address Group Objects. - For example: `tigera_api_user_profile` -1. Create a REST API Administrator, associate this user with the `tigera_api_user_profile` profile, and add the CIDR or IP address of your Kubernetes cluster nodes as trusted hosts. - For example: `calico_enterprise_api_user` -1. Note the API key. - -### Configure FortiManager to communicate with firewall controller - -1. Determine and note the CIDR's or IP addresses of all Kubernetes nodes that can run the `tigera-firewall-controller`. - Required to explicitly allow the tigera-firewall-controller to access the FortiManager API. -1. From system settings, create an Admin profile with Read-Write access for `Policy & Objects`. - For example: `tigera_api_user_profile` -1. Create a JSON API administrator, associate this user with the `tigera_api_user_profile` profile, and add the CIDR or IP address of your Kubernetes cluster nodes as `Trusted Hosts`. -1. Note the username and password. - -### Create a config map for address selection in firewall controller - -1. Create a namespace for tigera-firewall-controller. - - ```bash - kubectl create namespace tigera-firewall-controller - ``` - -1. Create a config map with FortiGate firewall information. - - For example: - - ```bash - kubectl -n tigera-firewall-controller create configmap tigera-firewall-controller \ - --from-literal=tigera.firewall.policy.selector="projectcalico.org/tier == 'default'" \ - --from-literal=tigera.firewall.addressSelection="node" - ``` - - **ConfigMap values** - - | Field | Enter values... | - | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | - | tigera.firewall.policy.selector | The tier name with the global network policies with the Fortigate address group mappings.
For example, this selects the global network policies in the `default` tier:
`tigera.firewall.policy.selector: "projectcalico.org/tier == 'default'" | - | tigera.firewall.addressSelection | The addressSelection for outbound traffic leaving the cluster.
For example, if outgoingNat is enabled in cluster and compute Node IP address is used "tigera.firewall.addressSelection == `node` or
If pod IP address used then "tigera.firewall.addressSelection == `pod`" | - -### Create a config map with FortiGate and FortiManager information - -1. In the [Fortigate ConfigMap manifest]($[filesUrl_CE]/manifests/fortinet-device-configmap.yaml), add your FortiGate firewall information in the data section, `tigera.firewall.fortigate`. - - Where: - - | Field | Description | - | ------------------------ | --------------------------------------------------------------------------- | - | name | FortiGate device name | - | ip | FortiGate Management Ip address | - | apikey | Secret in tigera-firewall-controller namespace, to store FortiGate's APIKey | - | apikey.secretKeyRef.name | Name of the secret to store APIKey. | - | apikey.secretKeyRef.key | Key name in the secret, which stores APIKey | - - For example: - - ```yaml - - name: prod-eastcoast-1 - ip: 1.2.3.1 - apikey: - secretKeyRef: - name: fortigate-east1 - key: apikey-fortigate-east1 - - name: prod-eastcoast-2 - ip: 1.2.3.2 - apikey: - secretKeyRef: - name: fortigate-east2 - key: apikey-fortigate-east2 - ``` - -1. In the [FortiManager ConfigMap manifest]($[filesUrl_CE]/manifests/fortinet-device-configmap.yaml), add your FortiManager information in the data section, `tigera.firewall.fortimgr`. - - Where: - - | Field | Description | - | -------------------------- | ------------------------------------------------------------------------------ | - | name | FortiManager device name | - | ip | FortiManager Management Ip address | - | adom | FortiManager ADOM name to manage kubernetes cluster. | - | username | JSON api access account name to Read/Write FortiManager address objects. | - | password | Secret in tigera-firewall-controller namespace, to store FortiManager password | - | password.secretKeyRef.name | Name of the secret to store password. | - | password.secretKeyRef.key | Key name in the secret, which stores password. | - - For example: - - ```yaml - - name: prod-east1 - ip: 1.2.4.1 - username: api_user - adom: root - password: - secretKeyRef: - name: fortimgr-east1 - key: pwd-fortimgr-east1 - ``` - -:::note - -If you are not using FortiManager in the integration, include only the following field in the ConfigMap data section. `tigera.firewall.fortimgr: |` - -::: - -1. Apply the manifest. - - ``` - kubectl apply -f $[filesUrl_CE]/manifests/fortinet-device-configmap.yaml - ``` - -### Install FortiGate ApiKey and FortiManager password as secrets - -1. Store each FortiGate API key as a secret in the `tigera-firewall-controller` namespace. - For example, the FortiGate device, `prod-east1`, store its ApiKey as a secret name as `fortigate-east1`, with key as `apikey-fortigate-east1`. - - ``` - kubectl create secret generic fortigate-east1 \ - -n tigera-firewall-controller \ - --from-literal=apikey-fortigate-east1=
- FE (frontend pods)
- BE (backend pods) | -| NetworkSet | An arbitrary set of IP subnetworks/CIDRs or domains that can be matched by standard label selectors in Kubernetes or $[prodname] network policy. Network sets are a $[prodname] namespaced resource. | -| GlobalNetwork Set | An arbitrary set of IP subnetworks/CIDRs or domains that can be matched by standard label selectors in Kubernetes or $[prodname] network policy. Global network sets are a $[prodname] global resource. | -| ServiceAccount | Provides an identity for processes that run in a pod. Service accounts are a Kubernetes namespaced resource. | -| HostEndpoint (HEP) | Physical or virtual interfaces attached to a host that runs $[prodname]. HEPs enforce $[prodname] policy on the traffic that enters or leaves the host’s default network namespace through the interfaces. HEPs are a $[prodname] global resource. | -| External component | A machine (physical or virtual) that runs outside of the Kubernetes cluster. | - -## Create a network policy - -To follow along in Manager UI, click **Policies**. - -There are three main parts to every $[prodname] policy: - -- **Scope** - namespace or global -- **Applies to** - objects within the above scope to which policy rules will be applied using labels and selectors -- **Type** - whether this policy affects ingress, egress, or both - - Ingress - policy rules to apply to connections inbound to the selected objects - - Egress - policy rules to apply to connections outbound from the selected objects - - - -Let's look at each part. - -## Scope - -Scope defines the reach of your policy. Use this dropdown to determine whether your policy applies globally or to a specific namespace. Think of scope as the "top-level scope" that can be further specified using the "Applies to" selection that follows. - -- **Global** - - If you select global, but do not add entries in the **Applies to** field to further limit scope, _every pod and host endpoint (HEP) in our cluster would be in scope_. The following example uses the global option to limit the scope to all pods and HEPs (noted by check marks). - -  - -- **Namespace** - - If you select namespace, but do not add entries in the **Applies to** field to further limit scope, _every pod in this policy's namespace would be in scope_. The following example uses the namespace option to limit the scope to pods in the RED namespace. - -  - -### Applies to - -As discussed above, selecting **Applies to** lets you further limit pods in a policy. You can think of it as the "top-level endpoint selector". You define labels on your endpoints, namespaces, and service accounts, then use label selectors to limit connections by matching the following object types: - -- **Endpoints** - - Specify one or more label selectors to match specific endpoints, or select all endpoints - -- **Namespaces** (available only when the Scope is global) - - Specify one or more label selectors to match specific namespaces, or select all namespaces - -- **Service Accounts** - - Specify or more label selectors to match specific service accounts, or select all service accounts - -For example, if we select the BLUE namespace and apply it to only pods with the label, `app/tier == FE`, - - - -the resulting scope in our diagram would be only the pods labeled, `FE`: - - - -### Type - -In the Type section, you specify whether the policy impacts ingress, egress, or both. - -Note that ingress and egress are defined from the point of view of the _scoped endpoints_ (pods or host endpoints). In the previous diagram, the scoped endpoints are the three pods labeled, `app/tier:FE`. - -- Ingress rules filter traffic _coming to_ the scoped endpoints -- Egress rules filter traffic _leaving_ the scoped endpoints - -Select the **Ingress** rule, and click **+ Add ingress rule** to access the **Create New Policy rules** page. - -### Endpoint selector - -The endpoint selector lets you select the endpoint traffic that is matched within the scope you've defined in the policy. - -In our example, the policy is scoped to endpoints that have the `app/tier == FE` label in the BLUE namespace. In the context of an egress rule, when we add the `app/tier == BE` endpoint selector, all TCP traffic from endpoints that have the`app/tier == BE` label will be allowed to the `app/tier == FE` endpoints. - - - -Note that endpoints that have the `app/tier == BE` label in other namespaces are not matched because the policy is namespace scoped. - -### Namespace selector - -This is where things can get interesting. In the previous example, we did not select anything in the namespace selector. Let's change the namespace selector to have both the BLUE and GREEN namespaces. - - - -Although the overall policy is scoped to the BLUE namespace, we can match endpoints in other namespaces on a per-rule basis. Note that the top-level scope that you select remains unchanged, meaning that the policy is still applied only to endpoints in the BLUE namespace. - - - -### Network selector - -Using the Nets selector, we can add CIDR addresses to be matched by the policy rule. - - - -### Service account selector - -Network policies can be also applied to the endpoint’s service account. - -Using the service account selector, we can apply rules to traffic from any endpoint whose service account matches the name or label selector. - - - -### Use Match All for wider matches in policy rules - -The **Match All** policy rule (`all()` in YAML) matches traffic for: - -- All endpoints in a namespace (if the policy scope is namespace) -- All endpoints (if the policy scope is global) - -Let's look at an example of using **Match All** traffic in a namespaced policy: - -- Scope is namespaced (BLUE) -- Applies to `app/tier == FE` - -Suppose we want to match traffic to the pod labeled `BE`, and the $[prodname] `networkset-1`. - - - -To do this, we can use the policy rule endpoint selector, **Match All**. - - - -Not only is the pod labeled `BE` included, but also the $[prodname] `networkset-1`. - - - -Note that we could have created individual selectors to match pods labeled, `BE` and for the `network-set-1`. - -**Match All traffic with namespace selectors** - -In the following example, if we select **Match All** endpoints, but in the **Namespace selector**, we select both the BLUE and GREEN namespaces, the results for matching are: all pods and network sets in the BLUE and GREEN namespaces. - - - -**Global selector** - -Let's see what happens when we select the **Global** selector. - - - -In our example, the Global selector selects HEPs and global network sets are selected. You might think that Global (`global()` in YAML) would select all endpoints, but it doesn't. Global means "do not select any namespaced resources" (which includes namespaced network set resources). Another way to express it is, do not select any workload endpoints. - - - -**Endpoint selector, unspecified** - -Next, let's see what happens when the policy rule does not specify any selection criteria. In this example, the rule selects all workloads, network sets, endpoints, and host endpoints within scope of the policy, including external components (the VM database). - - - -Now that you know the basic elements of a network policy, let's move on to policy ordering and tiers. - -## Policy ordering - -$[prodname] policies can have order values that control the order of precedence. For both network policies and global network policies, $[prodname] applies the policy with the lowest value first. - - - -### Mixing Kubernetes and $[prodname] policies - -Kubernetes and $[prodname] policies work side by side without a problem. However, Kubernetes network policies cannot assign an order value, so $[prodname] will set an implicit order value of 1000 to any Kubernetes network policies. - -:::note -Policies are immediately applied to any new connections. However, for existing connections that are already open, the policy changes will only take effect after the connection has been reestablished. This means that any ongoing sessions may not immediately reflect policy changes until they are initiated again. -::: - -### $[prodname] policies with no order value - -$[prodname] policies with order values take precedence. Policies without order values take lesser precedence and are processed alphabetically. - -## Tiers - -Tiers are a hierarchical construct used to group policies and enforce higher precedence policies that cannot be circumvented by other teams. Access to tiers is controlled using user role permissions. For example, a security team can implement high-level policy (for example, blocking access to/from IP ranges in particular countries), while developers in a later tier can control specific rules for the microservices of an app running in the cluster. - -### Policy processing overview - -When a new connection is processed by $[prodname], each tier that contains a policy that selects the endpoint processes the connection. Tiers are sorted by their order - the smallest number first. Policies in each tier are then processed in order from lowest to highest. For example, a policy of 800 is ordered before a policy of order 1000. - -- If a network policy or global network policy in the tier allows or denies the connection, then evaluation is done: the connection is handled accordingly. - -- If a network policy or global network policy in the tier passes the connection, the next tier containing a policy that selects the endpoint processes the connection - -After a Pass action, if no subsequent tier contains any policies that apply to the pod, the connection is allowed. - -If the tier contains policies that apply to the endpoint, but the policies take no action on the connection, the connection is dropped by an implicit deny. - -If no tiers contain policies that apply to the endpoint, the connection is allowed by an implicit allow. - -### Policies with no order value - -You can create policies without an order value. When a policy with no order value is placed in a tier with other policies that do have an order value, the policies are processed as follows: - -- Policies are evaluated from smallest to largest order value within the tier -- Policies with no order value are processed last in the tier, but before the implicit deny -- When multiple policies without an order value are present in a tier, they are processed in alphabetical order. However, we do not recommended relying on alphabetical ordering because it hard to operationalize. - -### How policy action rules affect traffic processing - -It is also important to understand that $[prodname] policy action rules affect how traffic and connections are processed. Let's go back to the drop-down menu on the Create New Policy Rule page. - -Action defines what should happen when a connection matches this rule. - - - -- **Allow or Deny** - traffic is allowed or denied and the connection is handled accordingly. No further rules are processed. -- **Pass** - skips to the next tier that contains a policy that applies to the endpoint, and processes the connection. If the tier applies to the endpoint but no action is taken on the connection, the connection is dropped. -- **Log** - creates a log, and evaluation continues processing to the next rule - -## Additional resources - -The following topics go into further detail about concepts described in this tutorial: - -- [Get started with network policy](../beginners/calico-network-policy.mdx) -- [Service account selectors](../beginners/policy-rules/service-accounts.mdx) -- [Get started with tiered network policy](tiered-policy.mdx) -- [Get started with network sets](../networksets.mdx) diff --git a/calico-cloud_versioned_docs/version-20-1/network-policy/policy-tiers/rbac-tiered-policies.mdx b/calico-cloud_versioned_docs/version-20-1/network-policy/policy-tiers/rbac-tiered-policies.mdx deleted file mode 100644 index 7258ca452e..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/network-policy/policy-tiers/rbac-tiered-policies.mdx +++ /dev/null @@ -1,518 +0,0 @@ ---- -description: Configure RBAC to control access to policies and tiers. ---- - -# Configure RBAC for tiered policies - -## Big picture - -Configure fine-grained user access controls for tiered policies. - -## Value - -Self-service is an important part of CI/CD processes for containerization and microservices. $[prodname] provides fine-grained access control (RBAC) for: - -- $[prodname] policy and tiers -- Kubernetes network policy - -## Concepts - -### Standard Kubernetes RBAC - -$[prodname] implements the standard **Kubernetes RBAC Authorization APIs** with `Role` and `ClusterRole` types. The $[prodname] API server integrates with Kubernetes RBAC Authorization APIs as an extension API server. - -### RBAC for policies and tiers - -In $[prodname], global network policy and network policy resources are associated with a specific tier. Admins can configure access control for these $[prodname] policies using standard Kubernetes `Role` and `ClusterRole` resource types. This makes it easy to manage RBAC for both Kubernetes network policies and $[prodname] tiered network policies. RBAC permissions include managing resources using $[prodname] Manager, and `kubectl`. - -### Fine-grained RBAC for policies and tiers - -RBAC permissions can be split by resources ($[prodname] and Kubernetes), and by actions (CRUD). Tiers should be created by administrators. Full CRUD operations on tiers is synonymous with full management of network policy. Full management to network policy and global network policy also requires `GET` permissions to 1) any tier a user can view/manage, and 2) the required access to the tiered policy resources. - -Here are a few examples of how you can fine-tune RBAC for tiers and policies. - -| **User** | **Permissions** | -| --------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| Admin | The default **tigera-network-admin** role lets you create, update, delete, get, watch, and list all $[prodname] resources (full control). Examples of limiting Admin access:
- List tiers only
- List only specific tiers
- Read-only access to all policy resources across all tiers, but only write access for NetworkPolicies with a specific tier and namespace.
- Perform any operations on NetworkPolicies and GlobalNetworkPolicies.
- List tiers only.
- List or modify any policies in any tier. Fully manage only Kubernetes network policies in the **default** tier, in the **default** namespace, with read-only access for all other tiers.
- With OpenShift, also add a toplevel `platform: openshift` setting. - - :::note - - `platform: openshift` triggers additional per-node setup that is needed - during OpenShift's bootstrapping phase. - - ::: - - For example, with IP addresses and AS numbers similar as for other resources above: - - ```yaml noValidation - apiVersion: projectcalico.org/v3 - kind: EarlyNetworkConfiguration - spec: - platform: openshift - nodes: - # worker1 - - interfaceAddresses: - - 172.31.11.3 - - 172.31.12.3 - stableAddress: - address: 172.31.10.3 - asNumber: 65001 - peerings: - - peerIP: 172.31.11.100 - - peerIP: 172.31.12.100 - labels: - rack: ra - # worker2 - - interfaceAddresses: - - 172.31.21.4 - - 172.31.22.4 - stableAddress: - address: 172.31.20.4 - asNumber: 65002 - peerings: - - peerIP: 172.31.21.100 - - peerIP: 172.31.22.100 - labels: - rack: rb - ... - ``` - -1. Prepare a ConfigMap resource named "bgp-layout", in namespace "tigera-operator", that - wraps the EarlyNetworkConfiguration like this: - - ```yaml noValidation - apiVersion: v1 - kind: ConfigMap - metadata: - name: bgp-layout - namespace: tigera-operator - data: - earlyNetworkConfiguration: | - apiVersion: projectcalico.org/v3 - kind: EarlyNetworkConfiguration - spec: - nodes: - # worker1 - - interfaceAddresses: - ... - ``` - -:::note - -EarlyNetworkConfiguration supplies labels and AS numbers to apply to each -Calico node, as well as peering and other network configuration to use during node -startup prior to receiving BGPPeer and BGPConfiguration resources from the datastore. -EarlyNetworkConfiguration will be superseded by any BGPPeer or BGPConfiguration -resources after successful startup. - -::: - -### Arrange for dual-homed nodes to run $[nodecontainer] on each boot - -$[prodname]'s $[nodecontainer] image normally runs as a Kubernetes pod, but -for dual ToR setup it must also run as a container after each boot of a dual-homed node. -For example: - -``` -podman run --privileged --net=host \ - -v /calico-early:/calico-early -e CALICO_EARLY_NETWORKING=/calico-early/cfg.yaml \ - $[registry]$[imageNames.node]:latest -``` - -The environment variable `CALICO_EARLY_NETWORKING` must point to the -EarlyNetworkConfiguration prepared above, so that EarlyNetworkConfiguration YAML must be -copied into a file on the node (here, `/calico-early/cfg.yaml`) and mapped into the -$[nodecontainer] container. - -We recommend defining systemd services to ensure that early networking runs on each boot, -and before kubelet starts on the node. Following is an example that may need tweaking for -your particular platform, but that illustrates the important points. - -Firstly, a "calico-early" service that runs the Calico early networking on each boot: - -``` -[Unit] -Wants=network-online.target -After=network-online.target -After=nodeip-configuration.service -[Service] -ExecStartPre=/bin/sh -c "rm -f /etc/systemd/system/kubelet.service.d/20-nodenet.conf /etc/systemd/system/crio.service.d/20-nodenet.conf; systemctl daemon-reload" -ExecStartPre=-/bin/podman rm -f calico-early -ExecStartPre=/bin/mkdir -p /etc/calico-early -ExecStartPre=/bin/sh -c "test -f /etc/calico-early/details.yaml || /bin/curl -o /etc/calico-early/details.yaml http://172.31.1.1:8080/calico-early/details.yaml" -ExecStart=/bin/podman run --rm --privileged --net=host --name=calico-early -v /etc/calico-early:/etc/calico-early -e CALICO_EARLY_NETWORKING=/etc/calico-early/details.yaml $[registry]$[imageNames.node]:latest -[Install] -WantedBy=multi-user.target -``` - -:::note - -- You must also install your Tigera-issued pull secret at `/root/.docker/config.json`, - on each node, to enable pulling from $[registry]. -- Some OpenShift versions have a `nodeip-configuration` service that configures - kubelet's `--node-ip` option **wrongly** for a dual ToR setup. The - `After=nodeip-configuration.service` setting and the deletion of `20-nodenet.conf` - undo that service's work so that kubelet can choose its own IP correctly (using a - reverse DNS lookup). -- The `/bin/curl ...` line shows how you can download the EarlyNetworkConfiguration - YAML from a central hosting point within your cluster. - -::: - -Secondly, a "calico-early-wait" service that delays kubelet until after the Calico early -networking setup is in place: - -``` -[Unit] -After=calico-early.service -Before=kubelet.service -[Service] -Type=oneshot -ExecStart=/bin/sh -c "while sleep 5; do grep -q 00000000:1FF3 /proc/net/tcp && break; done; sleep 15" -[Install] -WantedBy=multi-user.target -``` - -:::note - -- The `ExecStart` line here arranges that kubelet will not start running until the - calico-early service has started listening on port 8179 (hex `1FF3`). 8179 is the - port that the calico-early service uses for pre-Kubernetes BGP. -- We have sometimes observed issues if kubelet starts immediately after Calico's early - networking setup, because of NetworkManager toggling the hostname. The final `sleep 15` allows for such changes to settle down before kubelet starts. - -::: - -On OpenShift you should wrap the above service definitions in `MachineConfig` resources -for the control and worker nodes. - -On other platforms either define and enable the above services directly, or use -whatever API the platform provides to define and enable services on new nodes. - -### Configure your ToR routers and infrastructure - -You should configure your ToR routers to accept all the BGP peerings from -$[prodname] nodes, to reflect routes between the nodes in that rack, and to -propagate routes between the ToR routers in different racks. In addition we recommend -consideration of the following points. - -BFD should be enabled if possible on all BGP sessions - both to the $[prodname] -nodes, and between racks in your core infrastructure - so that a break in connectivity -anywhere can be rapidly detected. The handling should be to initiate LLGR procedures if -possible, or else terminate the BGP session non-gracefully. - -LLGR should be enabled if possible on all BGP sessions - again, both to the -$[prodname] nodes, and between racks in your core infrastructure. Traditional BGP -graceful restart should not be used, because this will delay the cluster's response to a -break in one of the connectivity planes. - -### Install Kubernetes and $[prodname] - -Details here vary, depending on **when** your Kubernetes installer gives an opportunity -for you to define custom resources, but fundamentally what is needed here is to perform -the installation as usual, except that all of the Calico resources prepared above, except -the EarlyNetworkConfiguration, must be added into the datastore **before** the -$[nodecontainer] pods start running on any node. We can illustrate this by looking -at two examples: with OpenShift, and when adding Calico to an existing Kubernetes cluster. - -**OpenShift** - -With OpenShift, follow our documentation as -far as the option to provide additional configuration. - -Then use `kubectl create configmap ...`, as that documentation says, to combine the -prepared BGPPeer, BGPConfiguration and IPPool resources into a `calico-resources` -ConfigMap. Place the generated file in the manifests directory for the OpenShift install. - -Also place the "bgp-layout" ConfigMap file in the manifests directory. - -Now continue with the OpenShift install process, and it will take care of adding those -resources into the datastore as early as possible. - -**Adding to an existing Kubernetes cluster** - -Follow our documentation - -as -far as the option for installing any custom Calico resources. Then use `calicoctl`, as -that documentation says, to install the prepared BGPPeer, BGPConfiguration and IPPool -resources. - -Also use `kubectl` to install the "bgp-layout" ConfigMap. - -Now continue with the $[prodname] install process, and you should observe each node -establishing BGP sessions with its ToRs. - -### Verify the deployment - -If you examine traffic and connections within the cluster - for example, using `ss` or -`tcpdump` - you should see that all connections use loopback IP addresses or pod CIDR IPs -as their source and destination. For example: - -- The kubelet on each node connecting to the API server. - -- The API server's connection to its backing etcd database, and peer connections between - the etcd cluster members. - -- Pod connections that involve an SNAT or MASQUERADE in the data path, as can be the case - when connecting to a Service through a cluster IP or NodePort. At the point of the - SNAT or MASQUERADE, a loopback IP address should be used. - -- Direct connections between pod IPs on different nodes. - -The only connections using interface-specific addresses should be BGP. - -:::note - -If you plan to use [Egress Gateways](../egress/egress-gateway-on-prem.mdx) in your cluster, you must also adjust the $[nodecontainer] IP -auto-detection method to pick up the stable IP, for example using the `interface: lo` setting -(The default first-found setting skips over the lo interface). This can be configured via the -$[prodname] [Installation resource](../../reference/installation/api.mdx#operator.tigera.io/v1.NodeAddressAutodetection). - -::: - -If you look at the Linux routing table on any cluster node, you should see ECMP routes -like this to the loopback address of every other node in other racks: - -``` -172.31.20.4/32 - nexthop via 172.31.11.250 dev eth0 - nexthop via 172.31.12.250 dev eth1 -``` - -and like this to the loopback address of every other node in the same rack: - -``` -172.31.10.4/32 - nexthop dev eth0 - nexthop dev eth1 -``` - -If you launch some pods in the cluster, you should see ECMP routes for the /26 IP blocks -for the nodes where those pods were scheduled, like this: - -``` -10.244.192.128/26 - nexthop via 172.31.11.250 dev eth0 - nexthop via 172.31.12.250 dev eth1 -``` - -If you do something to break the connectivity between racks of one of the planes, you -should see, within only a few seconds, that the affected routes change to have a single -path only, via the plane that is still unbroken; for example: - -``` -172.31.20.4/32 via 172.31.12.250 dev eth1` -10.244.192.128/26 via 172.31.12.250 dev eth1 -``` - -When the connectivity break is repaired, those routes should change to become ECMP again. diff --git a/calico-cloud_versioned_docs/version-20-1/networking/configuring/index.mdx b/calico-cloud_versioned_docs/version-20-1/networking/configuring/index.mdx deleted file mode 100644 index a32ec45aa3..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/networking/configuring/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Configure Calico networking options. -hide_table_of_contents: true ---- - -# Configure Calico Cloud networking - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - -
- -### Expose gateway maintenance annotations to your application - -While the presence of gateway maintenance annotations may be useful to a cluster administrator inspecting pods, it's not quite enough if our workload wishes to react to terminating egress gateways, say, by restarting its session gracefully before loss of connectivity. - -The [Kubernetes downward API](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#the-downward-api) provides a means of exposing pod information [as files](https://kubernetes.io/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/#store-pod-fields) or as [environment variables](https://kubernetes.io/docs/tasks/inject-data-application/environment-variable-expose-pod-information/#use-pod-fields-as-values-for-environment-variables) within the pod. This value can then be polled by your workload, to react to changes as you see fit. - -Let's write a simple pod manifest that uses the downward API to expose maintenance annotations to the program running within: - -```yaml -apiVersion: v1 -kind: Pod -metadata: - annotations: - egress.projectcalico.org/selector: egress-code == 'red' - egress.projectcalico.org/namespaceSelector: projectcalico.org/name == 'default' - name: poll-my-own-annotations - namespace: default -spec: - containers: - - name: application-container - image: k8s.gcr.io/busybox:1.24 - command: ['sh', '-c'] - args: - - while true; do - echo 'polling egress maintenance timestamp...'; - if [[ -e /var/run/egress/gatewayMaintenanceStartedTimestamp ]]; then - echo -n 'gatewayMaintenanceStartedTimestamp has value "'; cat /var/run/egress/gatewayMaintenanceStartedTimestamp; echo -en '"\n'; - fi; - sleep 3; - done; - volumeMounts: - - name: egress-maintenance-started - mountPath: /var/run/egress - volumes: - - name: egress-maintenance-started - downwardAPI: - items: - - path: 'gatewayMaintenanceStartedTimestamp' - fieldRef: - fieldPath: metadata.annotations['egress.projectcalico.org/gatewayMaintenanceStartedTimestamp'] -``` - -This sample manifest will create a pod whose `gatewayMaintenanceStartedTimestamp` annotation is mounted to the file `/var/run/egress/gatewayMaintenanceStartedTimestamp`. The pod's main process is a script which polls the value of this file. - -After deleting an egress gateway this workload relies on, let's check its logs: - -```sh -$ kubectl logs poll-my-own-annotations -polling egress maintenance timestamp... -gatewayMaintenanceStartedTimestamp has value "" -polling egress maintenance timestamp... -gatewayMaintenanceStartedTimestamp has value "" -polling egress maintenance timestamp... -gatewayMaintenanceStartedTimestamp has value "" -polling egress maintenance timestamp... -gatewayMaintenanceStartedTimestamp has value "2022-04-19T17:24:46Z" -polling egress maintenance timestamp... -gatewayMaintenanceStartedTimestamp has value "2022-04-19T17:24:46Z" -``` - -We can see above that our script saw the value of the mounted volume change at the same time what we terminated our egress gateway pod. This work can be further developed to propagate notifications to our production workloads, without any need for polling kubernetes itself. - -**Note**: It's not recommended to couple your production applications to a Kubernetes client for the purposes of polling pod information, as it could give an attacker greater privileges if successful in compromising a workload. Instead, use a method such as the downward API that fully decouples the program. - -
- -### Reduce the impact of gateway downtime - -So far we have observed egress gateway maintenance windows, added a termination grace period to gateway pods, and propagated maintenance information directly to our workloads. Finally, we are going to look at the `maxNextHops` annotation, which is designed to limit the impact of a terminating egress gateway. - -Below is a sample kubernetes deployment which was adapted from the earlier annotation-aware pod manifest. The deployment has 3 replicas, and is configured to use egress gateways: - -```yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: annotation-aware-workloads -spec: - replicas: 3 - selector: - matchLabels: - app: annotation-aware-workload - strategy: - rollingUpdate: - maxSurge: 25% - maxUnavailable: 25% - type: RollingUpdate - template: - metadata: - labels: - app: annotation-aware-workload - annotations: - egress.projectcalico.org/selector: egress-code == 'red' - egress.projectcalico.org/namespaceSelector: projectcalico.org/name == 'default' - spec: - containers: - - name: application-container - image: k8s.gcr.io/busybox:1.24 - command: ['sh', '-c'] - args: - - while true; do - echo "[${MY_POD_NAME}] polling egress maintenance timestamp..."; - if [[ -e /var/run/egress/gatewayMaintenanceStartedTimestamp ]]; then - echo -n "[${MY_POD_NAME}] gatewayMaintenanceStartedTimestamp has value '"; cat /var/run/egress/gatewayMaintenanceStartedTimestamp; echo -en "'\n"; - fi; - sleep 3; - done; - volumeMounts: - - name: egress-maintenance-started - mountPath: /var/run/egress - env: - - name: MY_POD_NAME - valueFrom: - fieldRef: - fieldPath: metadata.name - volumes: - - name: egress-maintenance-started - downwardAPI: - items: - - path: 'gatewayMaintenanceStartedTimestamp' - fieldRef: - fieldPath: metadata.annotations['egress.projectcalico.org/gatewayMaintenanceStartedTimestamp'] -``` - -#### Observing the impact of egress gateway maintenance - -We now want to conduct maintenance on a particular node in our cluster, resulting in one of our egress gateways terminating. In this scenario, since our dependent applications' connections are load-balanced evenly across all available egress gateways, all of our application pods will receive a maintenance window annotation. If we have configured our applications to react to such a window, we will see them all react at once in a thundering herd: - -```sh -$ begin the termination of an egress gateway pod -$ kubectl delete pod egress-gateway-6576ccdf66-mtqzl --wait=false -pod "egress-gateway-6576ccdf66-mtqzl" deleted - -$ lets collect logs from all pods in our maintenance-aware application deployment -$ kubectl logs --selector=app=annotation-aware-workload -[annotation-aware-workloads-7987f55c9f-f7mkq] polling egress maintenance timestamp... -[annotation-aware-workloads-7987f55c9f-f7mkq] gatewayMaintenanceStartedTimestamp has value '' -[annotation-aware-workloads-7987f55c9f-qtcs2] polling egress maintenance timestamp... -[annotation-aware-workloads-7987f55c9f-qtcs2] gatewayMaintenanceStartedTimestamp has value '' -[annotation-aware-workloads-7987f55c9f-z5x25] polling egress maintenance timestamp... -[annotation-aware-workloads-7987f55c9f-z5x25] gatewayMaintenanceStartedTimestamp has value '' -[annotation-aware-workloads-7987f55c9f-qtcs2] polling egress maintenance timestamp... -[annotation-aware-workloads-7987f55c9f-qtcs2] gatewayMaintenanceStartedTimestamp has value '2022-04-20T12:24:34Z' -[annotation-aware-workloads-7987f55c9f-f7mkq] polling egress maintenance timestamp... -[annotation-aware-workloads-7987f55c9f-f7mkq] gatewayMaintenanceStartedTimestamp has value '2022-04-20T12:24:34Z' -[annotation-aware-workloads-7987f55c9f-z5x25] polling egress maintenance timestamp... -[annotation-aware-workloads-7987f55c9f-z5x25] gatewayMaintenanceStartedTimestamp has value '2022-04-20T12:24:34Z' -``` - -We can see in the above logs that all of our applications have been affected by the downtime of just a single egress gateway. In the worst case, this could lead to a window of downtime for the application, as all replicas scramble to restart their connections at once. To avoid this, lets use the `egress.projectcalico.org/maxNextHops` annotation to restrict the total number of gateways each application can depend on. - -#### Reducing the impact of egress gateway maintenance - -To place a limit on the number of egress gateways an application can depend on, annotate the application's pod with the `egress.projectcalico.org/maxNextHops` annotation. Alternatively, to limit all pods in a certain namespace, annotate that namespace. Let's annotate all pods in our sample deployment from earlier: - -```sh -kubectl patch deploy annotation-aware-workloads --type=merge -p \ -'{"spec": - {"template": - {"metadata": - {"annotations": - {"egress.projectcalico.org/maxNextHops": "1"} - } - } - } -}' -``` - -:::note - -- Either a _pod or a namespace_ can be annotated with `egress.projectcalico.org/maxNextHops`, however, the `egress.projectcalico.org/selector` annotation must also be present on the selected resource. -- If annotating pods, the `egressIPSupport` Felixconfiguration option must be set to `EnabledPerNamespaceOrPerPod`. -- If a pod's desired `maxNextHops` exceeds the total number of available egress gateways, scaling up the egress gateway deployment will result in the pod's egress networking updating until the desired number of gateways are being used. -- In all other cases, the `maxNextHops` annotation only takes effect at the time a pod is created. To ensure a pod's egress networking remains functional for its entire lifecycle, modifications to `maxNextHops` after a pod's creation will have no effect. For this reason, it's recommended that any egress gateway deployments have been scaled prior to deploying dependent workloads. - -::: - -After our patched sample deployment has been fully rolled out, each application pod should now depend on at most one egress gateway replica. Let's bring down another egress gateway pod and monitor our application logs: - -```sh -$ begin the termination of an egress gateway pod -$ kubectl delete pod egress-gateway-6576ccdf66-c42v7 --wait=false -pod "egress-gateway-6576ccdf66-c42v7" deleted - -$ collect logs from each application pod -$ kubectl logs --selector=app=annotation-aware-workload -[annotation-aware-workloads-565b6855b9-tjvqr] polling egress maintenance timestamp... -[annotation-aware-workloads-565b6855b9-tjvqr] gatewayMaintenanceStartedTimestamp has value '' -[annotation-aware-workloads-565b6855b9-s44pt] polling egress maintenance timestamp... -[annotation-aware-workloads-565b6855b9-s44pt] gatewayMaintenanceStartedTimestamp has value '' -[annotation-aware-workloads-565b6855b9-46cw5] polling egress maintenance timestamp... -[annotation-aware-workloads-565b6855b9-46cw5] gatewayMaintenanceStartedTimestamp has value '' -[annotation-aware-workloads-565b6855b9-tjvqr] polling egress maintenance timestamp... -[annotation-aware-workloads-565b6855b9-tjvqr] gatewayMaintenanceStartedTimestamp has value '2022-04-20T12:53:32Z' -[annotation-aware-workloads-565b6855b9-s44pt] polling egress maintenance timestamp... -[annotation-aware-workloads-565b6855b9-s44pt] gatewayMaintenanceStartedTimestamp has value '' -[annotation-aware-workloads-565b6855b9-46cw5] polling egress maintenance timestamp... -[annotation-aware-workloads-565b6855b9-46cw5] gatewayMaintenanceStartedTimestamp has value '' -``` - -We can see from the above logs that only a single application pod has now been affected by the terminating egress gateway. The other pods have not received an annotation for a terminating gateway because they have chosen different gateways to depend on, and thus won't be affected. - -:::note - -The subset of egress gateway replicas that each pod will depend on when using the `maxNextHops` annotation can't be manually selected. -$[prodname] selects a subset of replicas in such a way as to evenly distribute load across the whole replica set. - -::: - -
- -## Reference - -**The following are annotations that $[prodname] sets automatically on any egress-dependent pods:** - -| Annotation | Description | Datatype | Default value | Expected values | -| -------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ---------- | ------------- | ---------------------------------------------------- | -| `egress.projectcalico.org/gatewayMaintenanceGatewayIP` | Indicates the IP of a terminating egress gateway your pod is using. | IP Address | "" | Any IP within the egress gateway deployment's IPSet. | -| `egress.projectcalico.org/gatewayMaintenanceStartedTimestamp` | Indicates when the egress gateway identified by `gatewayMaintenanceGatewayIP` began terminating. | String | "" | An RFC3339 date string | -| `egress.projectcalico.org/gatewayMaintenanceFinishedTimestamp` | Indicates when the egress gateway identified by `gatewayMaintenanceGatewayIP` will finish terminating. | String | "" | An RFC3339 date string | - -
- -**The following annotations are used to configure your egress-dependent workloads. These annotations can be set either on a namespace, or on a pod. If setting the annotations on pods, the `egressIPSupport` FelixConfiguration option must be set to `EnabledPerNamespaceOrPerPod`.** - -| Annotation | Description | Datatype | Default value | Possible values | -| -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | ------------- | ----------------------- | -| `egress.projectcalico.org/maxNextHops` | Specifies the maximum number of egress gateway replicas from the selected deployment that a pod should depend on. Replicas will be chosen in a manner that attempts to balance load across the whole egress gateway replicaset. If unset, or set to "0", egress traffic will behave in the default manner (load balanced over all available gateways). | String | "" | "0", "1", "2", "3", ... | - -## Additional resources - -- [Troubleshooting egress gateways](troubleshoot.mdx). diff --git a/calico-cloud_versioned_docs/version-20-1/networking/egress/egress-gateway-on-prem.mdx b/calico-cloud_versioned_docs/version-20-1/networking/egress/egress-gateway-on-prem.mdx deleted file mode 100644 index 741aecc356..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/networking/egress/egress-gateway-on-prem.mdx +++ /dev/null @@ -1,587 +0,0 @@ ---- -description: Configure specific application traffic to exit the cluster through an egress gateway. -redirect_from: - - /compliance/egress-gateways ---- - -# Configure egress gateways, on-premises - -## Big picture - -Configure specific application traffic to exit the cluster through an egress gateway. - -## Value - -When traffic from particular applications leaves the cluster to access an external destination, it -can be useful to control the source IP of that traffic. For example, there may be an additional -firewall around the cluster, whose purpose includes policing external accesses from the cluster, and -specifically that particular external destinations can only be accessed from authorised workloads -within the cluster. - -$[prodname]'s own policy (including [DNS policy](../../network-policy/domain-based-policy.mdx)) and -per-node firewalls can ensure this, but deployments may like to deepen their defense by adding an -external firewall as well. If the external firewall is configured to allow outbound connections -only from particular source IPs, and the intended cluster workloads can be configured so that their -outbound traffic will have one of those source IPs, then the defense in depth objective is achieved. - -$[prodname] allows specifying an [IP pool](../../reference/resources/ippool.mdx) for each pod or namespace, and -even a [specific IP](../ipam/use-specific-ip.mdx) for a new pod, but this requires predicting how many pods -there will be representing a particular application, so that the IP pool can be correctly sized. -When IPs are a precious resource, over-sizing the pool is wasteful; but under-sizing is also -problematic, as then IPs will not be available within the desired range as the application is -scaled. - -Egress gateways provide an alternative approach. Application pods and namespaces are provisioned -with IPs from the default (and presumably plentiful) pool, but also configured so that their -outbound traffic is directed through an egress gateway. (Or, for resilience, through one of a small -number of egress gateways.) The egress gateways are set up to use a [specific IP pool](../ipam/legacy-firewalls.mdx) - and to perform an SNAT on the traffic passing through them. Hence, any -number of application pods can have their outbound connections multiplexed through a fixed small -number of egress gateways, and all of those outbound connections acquire a source IP from the egress -gateway IP pool. - -:::note - -The source port of an outbound flow through an egress gateway can generally _not_ be -preserved. Changing the source port is how Linux maps flows from many upstream IPs onto a single -downstream IP. - -::: - -Egress gateways are also useful if there is a reason for wanting all outbound traffic from a -particular application to leave the cluster through a particular node or nodes. For this case, the -gateways just need to be scheduled to the desired nodes, and the application pods/namespaces -configured to use those gateways. - -## Concepts - -### Egress gateway - -An egress gateway acts as a transit pod for the outbound application traffic that is configured to -use it. As traffic leaving the cluster passes through the egress gateway, its source IP is changed -to that of the egress gateway pod, and the traffic is then forwarded on. - -### Source IP - -When an outbound application flow leaves the cluster, its IP packets will have a source IP. -Normally this is the pod IP of the pod that originated the flow, or the node IP of the node hosting -that pod. It will be the **node IP** if the pod IP came from an [IP pool](../../reference/resources/ippool.mdx) with `natOutgoing: true`, and the **pod IP** if -not. (Assuming no other CNI plugin has been configured to NAT outgoing traffic.) - -With an egress gateway involved that is all still true, except that now it's the egress gateway that -counts, instead of the original application pod. So the flow will have the egress gateway's **node -IP**, if the egress gateway's pod IP came from an [IP pool](../../reference/resources/ippool.mdx) - with `natOutgoing: true`, and the egress -gateway's **pod IP** otherwise. - -### Control the use of egress gateways - -If a cluster ascribes special meaning to traffic flowing through egress gateways, it will be -important to control when cluster users can configure their pods and namespaces to use them, so that -non-special pods cannot impersonate the special meaning. - -If namespaces in a cluster can only be provisioned by cluster admins, one option is to enable egress -gateway function only on a per-namespace basis. Then only cluster admins will be able to configure -any egress gateway usage. - -Otherwise -- if namespace provisioning is open to users in general, or if it's desirable for egress -gateway function to be enabled both per-namespace and per-pod -- a [Kubernetes admission controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) - will be -needed. This is a task for each deployment to implement for itself, but possible approaches include -the following. - -1. Decide whether a given Namespace or Pod is permitted to use egress annotations at all, based on - other details of the Namespace or Pod definition. - -1. Evaluate egress annotation selectors to determine the egress gateways that they map to, and - decide whether that usage is acceptable. - -1. Impose the cluster's own bespoke scheme for a Namespace or Pod to identify the egress gateways - that it wants to use, less general than $[prodname]'s egress annotations. Then the - admission controller would police those bespoke annotations (that that cluster's users could - place on Namespace or Pod resources) and either reject the operation in hand, or allow it - through after adding the corresponding $[prodname] egress annotations. - -### Policy enforcement for flows via an egress gateway - -For an outbound connection from a client pod, via an egress gateway, to a destination outside the -cluster, there is more than one possible enforcement point for policy: - -The path of the traffic through policy is as follows: - -1. Packet leaves the client pod and passes through its egress policy. -2. The packet is encapsulated by the client pod's host and sent to the egress gateway -3. The encapsulated packet is sent from the host to the egress gateway pod. -4. The egress gateway pod de-encapsulates the packet and sends the packet out again with its own address. -5. The packet leaves the egress gateway pod through its egress policy. - -To ensure correct operation, (as of v3.15) the encapsulated traffic between host and egress gateway is auto-allowed by -$[prodname] and other ingress traffic is blocked. That means that there are effectively two places where -policy can be applied: - -1. on egress from the client pod -2. on egress from the egress gateway pod (see limitations below). - -The policy applied at (1) is the most powerful since it implicitly sees the original source of the traffic (by -virtue of being attached to that original source). It also sees the external destination of the traffic. - -Since an egress gateway will never originate its own traffic, one option is to rely on policy applied at (1) and -to allow all traffic to at (2) (either by applying no policy or by applying an "allow all"). - -Alternatively, for maximum "defense in depth" applying policy at both (1) and (2) provides extra protection should -the policy at (1) be disabled or bypassed by an attacker. Policy at (2) has the following limitations: - -- [Domain-based policy](../../network-policy/domain-based-policy.mdx) is not supported at egress from egress - gateways. It will either fail to match the expected traffic, or it will work intermittently if the egress gateway - happens to be scheduled to the same node as its clients. This is because any DNS lookup happens at the client pod. - By the time the policy reaches (2) the DNS information is lost and only the IP addresses of the traffic are available. - -- The traffic source will appear to be the egress gateway pod, the source information is lost in the address - translation that occurs inside the egress gateway pod. - -That means that policies at (2) will usually take the form of rules that match only on destination port and IP address, -either directly in the rule (via a CIDR match) or via a (non-domain based) NetworkSet. Matching on source has little -utility since the IP will always be the egress gateway and the port of translated traffic is not always preserved. - -:::note - -Since v3.15.0, $[prodname] also sends health probes to the egress gateway pods from the nodes where -their clients are located. In iptables mode, this traffic is auto-allowed at egress from the host and ingress -to the egress gateway. In eBPF mode, the probe traffic can be blocked by policy, so you must ensure that this traffic allowed; this should be fixed in an upcoming -patch release. - -::: - -## Before you begin - -**Unsupported** - -- GKE - -**Required** - -- Calico CNI -- Open port UDP 4790 on the host - -## How to - -- [Enable egress gateway support](#enable-egress-gateway-support) -- [Provision an egress IP pool](#provision-an-egress-ip-pool) -- [Deploy a group of egress gateways](#deploy-a-group-of-egress-gateways) -- [Configure iptables backend for egress gateways](#configure-iptables-backend-for-egress-gateways) -- [Configure namespaces and pods to use egress gateways](#configure-namespaces-and-pods-to-use-egress-gateways) -- [Optionally enable ECMP load balancing](#optionally-enable-ecmp-load-balancing) -- [Verify the feature operation](#verify-the-feature-operation) -- [Control the use of egress gateways](#control-the-use-of-egress-gateways) -- [Upgrade egress gateways](#upgrade-egress-gateways) - -### Enable egress gateway support - -In the default **FelixConfiguration**, set the `egressIPSupport` field to `EnabledPerNamespace` or -`EnabledPerNamespaceOrPerPod`, according to the level of support that you need in your cluster. For -support on a per-namespace basis only: - -```bash -kubectl patch felixconfiguration default --type='merge' -p \ - '{"spec":{"egressIPSupport":"EnabledPerNamespace"}}' -``` - -Or for support both per-namespace and per-pod: - -```bash -kubectl patch felixconfiguration default --type='merge' -p \ - '{"spec":{"egressIPSupport":"EnabledPerNamespaceOrPerPod"}}' -``` - -:::note - -- `egressIPSupport` must be the same on all cluster nodes, so you should set them only in the - `default` FelixConfiguration resource. -- The operator automatically enables the required policy sync API in the FelixConfiguration. - -::: - -### Provision an egress IP pool - -Provision a small IP Pool with the range of source IPs that you want to use for a particular -application when it connects to an external service. For example: - -```bash -kubectl apply -f - <
This could mean Fluentd is having trouble communicating with the Elasticsearch cluster, the Elasticsearch cluster is down, or there are simply too many logs to process. | diff --git a/calico-cloud_versioned_docs/version-20-1/operations/monitor/metrics/index.mdx b/calico-cloud_versioned_docs/version-20-1/operations/monitor/metrics/index.mdx deleted file mode 100644 index 1a154f4983..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/operations/monitor/metrics/index.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Configure Prometheus metrics. -hide_table_of_contents: true ---- - -# Metrics - -import DocCardList from '@theme/DocCardList'; -import { useCurrentSidebarCategory } from '@docusaurus/theme-common'; - -
Individual syncer values:
(typha_cache_size\{syncer="bgp"\}) (typha_cache_size\{syncer="dpi"\})(typha_cache_size\{syncer="felix"\})(typha_cache_size\{syncer="node-status"\}) (typha_cache_size\{syncer="tunnel-ip-allocation"\})Sum of all syncers:
The sum of all cache sizes (each syncer type has a cache).
sum by (instance) (typha_cache_size)Largest syncer:
max by (instance) (typha_cache_size) |
-| Example value | Example of: max by (instance) (typha_cache_size\{syncer="felix"\})\{instance="10.0.1.20:9093"\} 661\{instance="10.0.1.31:9093"\} 661 |
-| Explanation | The total number of key/value pairs in Typha's in-memory cache.This metric represents the scale of the $[prodname] datastore as it tracks how many WEPs (pods and services), HEPs (hostendpoints), networksets, globalnetworksets, $[prodname] Network Policies etc that Typha is aware of across the entire Calico Federation.You can use this metric to monitor individual syncers to Typha (like Felix, BGP etc), or to get a sum of all syncers. We recommend that you monitor the largest syncer but it is completely up to you. This is a good metric to understand how much data is in Typha. Note: If all Typhas are in sync then they should have the same value for this metric. |
-| Threshold value recommendation | The value of this metric will depend on the scale of the Calico Federation and will always increase as WEPs, $[prodname] network policies and clusters are added. Achieve a baseline first, then monitor for any unexpected increases from the baseline. |
-| Threshold breach symptoms | Unexpected increases may indicate memory leaks and performance issues with Typha. |
-| Threshold breach recommendations | Check CPU usage on Typha pods and Kubernetes nodes. Increase resources if needed, rollout and restart Typha(s) if needed. |
-| Priority level | Optional. |
-
-### CPU usage
-
-| CPU usage | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | rate(process_cpu_seconds_total\{30s\}) \* 100 |
-| Example value | \{endpoint="metrics-port", instance="10.0.1.20:9093", job="typha-metrics-svc", namespace="calico-system", pod="calico-typha-6c6cc9fcf7-csbdl", service="typha-metrics-svc"\} 0.27999999999999403 |
-| Explanation | CPU in use by Typha represented as a percentage of a core. |
-| Threshold value recommendation | A spike at startup is normal. It is recommended to achieve a baseline first, then monitor for any unexpected increases from this baseline. A rule of thumb is to investigate maintained CPU usage above 90%. |
-| Threshold breach symptoms | Unexpected maintained CPU usage could cause Typha to fall behind in updating its clients (for example, Felix) and could cause delays to policy updates. |
-| Threshold breach recommendations | Check CPU usage on Kubernetes nodes. If needed, increase resources, and rollout restart Typha(s). |
-| Priority level | Recommended. |
-
-### Memory usage
-
-| Memory usage | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | process_resident_memory_bytes |
-| Example value | process_resident_memory_bytes\{endpoint="metrics-port", instance="10.0.1.20:9093", job="typha-metrics-svc", namespace="calico-system", pod="calico-typha-6c6cc9fcf7-csbdl", service="typha-metrics-svc"\} 80515072 |
-| Explanation | Amount of memory used by Typha. |
-| Threshold value recommendation | It is recommended to achieve a baseline first, then monitor for any unexpected increases from this baseline. A rule of thumb is to investigate if maintained memory usage is above 90% of what is available from the underlying node. The metric can also be used for memory leaks. In this case, the metric would show Typhas' memory consumption rising over time, even though the cluster is in a stable state. |
-| Threshold breach symptoms | Unexpected maintained memory usage could cause Typha to fall behind in updating its clients (for example, Felix) and could cause delays to policy updates. |
-| Threshold breach recommendations | Check memory usage on Kubernetes nodes. Increase resources if needed, and rollout restart Typha(s) if needed. |
-| Priority level | Recommended. |
-
-## Typha cluster mesh metrics
-
-The following metrics are applicable only if you have implemented [Cluster mesh](multicluster/overview.mdx).
-
-Note that this metric requires a count syntax because you will have a copy of the metric per RemoteClusterConfiguration. As shown in the table, the value `2 = In Sync` reflects good connections.
-
-```
-remote_cluster_connection_status\{cluster="foo"\} = 2
-remote_cluster_connection_status\{cluster="bar"\} = 2
-remote_cluster_connection_status\{cluster="baz"\} = 1
-```
-
-### Remote cluster connections (in-sync)
-
-| Remote cluster connections (in-sync) | |
-| ------------------------------------ | ------------------------------------------------------------ |
-| Metric | count by (instance) (remote_cluster_connection_status == 2) |
-| Explanation | This represents the number of remote cluster connections that are connected and in sync. Each remote cluster will report a *connection_status* value from the following list:- 0 = Not Connected
- 1 = Connecting
- 2 = In Sync
- 3 = Resync in Process
- 4 = Config Change Restart Required
We suggest the count syntax because there will be one copy of *remote_cluster_connection_status* per cluster: -
remote_cluster_connection_status[cluster="foo"] = 2remote_cluster_connection_status[cluster="bar"] = 2remote_cluster_connection_status[cluster="baz"] = 'Counting the number of metrics with value 2 returns the number of In Sync clusters. | -| Threshold value recommendation | When remote cluster connections are initializing, *connection_status* values will fluctuate. After the connection is established, this value should be equal to the number of remote clusters in the environment (if everything is in sync). | -| Threshold breach symptoms | N/A
For out-of-sync symptoms, see the out-of-sync metric. | -| Threshold breach recommendations | N/A
For out-of-sync recommendations, see the out-of-sync metric. | -| Priority level | Recommended. | - -### Remote cluster connections (out-of-sync) - -The following metrics are applicable only if you have implemented [Cluster mesh](multicluster/overview.mdx). - -| Remote cluster connections (out-of-sync) | | -| ---------------------------------------- | ------------------------------------------------------------ | -| Metric |
count by (instance) (remote_cluster_connection_status != 2) |
-| Explanation | Number of remote cluster connections that are not in sync (i.e. resyncing or failing to connect). Each remote cluster will report a *connection_status* value from the following list:- 0 = Not Connected
- 1 = Connecting
- 2 = In Sync
- 3 = Resync in Process
- 4 = Config Change Restart Required | -| Threshold value recommendation | This value should be 2 if everything is in sync. Note: At Typha startup, it is normal to have non-2 values, but it should stabilize at 2 after connections come up. | -| Threshold breach symptoms | Typha will not receive updates from the relevant remote clusters. Connected clients will see stale or partial data from remote clusters. | -| Threshold breach recommendations | Investigate Typha's logs where remote cluster connectivity events are logged. Ensure the networking between clusters is not experiencing issues. | -| Priority level | Recommended. | - -## Typha client metrics - -### Total connections accepted - -| Total connections accepted | | -| -------------------------------- | ------------------------------------------------------------ | -| Metric |
typha_connections_accepted |
-| Example value | typha_connections_accepted\{endpoint="metrics-port", instance="10.0.1.20:9093", job="typha-metrics-svc", namespace="calico-system", pod="calico-typha-6c6cc9fcf7-csbdl", service="typha-metrics-svc"\} 10 |
-| Explanation | Total number of connections accepted over time. This value always increases. |
-| Threshold value recommendation | A steady increase over time is normal. Counters rising after a Felix or Typha restart is also normal (as clients get rebalanced). Investigate connection counters that rise rapidly with no Felix or Typha restarts. |
-| Threshold breach symptoms | Counters rising when there are no Felix or Typha restarts, or no action that could cause restarts (an upgrade for example), could indicate unexpected Felix or Typha restarts or issues. |
-| Threshold breach recommendations | Check resource usage on Typha(s) and Kubernetes nodes. Increase resources if needed. |
-| Priority level | Optional. |
-
-### Client connections actively streaming
-
-| Client connections actively streaming | |
-| ------------------------------------- | ------------------------------------------------------------ |
-| Metric | sum by (instance) (typha_connections_streaming) |
-| Example value | \{instance="10.0.1.20:9093"\} 10 \{instance="10.0.1.31:9093"\} 5 |
-| Explanation | Current number of active connections that are "streaming" (have completed the handshake), to this Typha. After a connection has been Accepted (reported in the previous metric), there will be a handshake before the connection is deemed to be actively streaming. This indicates how many clients are connected to a Typha. The sum reflects per-cache metrics as well. |
-| Threshold value recommendation | Compare the value for Total Connections Accepted and Client Connections Actively Streaming. The fluctuation of these values should be in-sync with each other if Accepted Connections are turning into Actively Streamed connections. If there is a discrepancy , you should investigate. Note: As always, it is recommended to baseline the relationship between these two metrics to have a sense of what is normal. It is also worth noting that in smaller clusters, it is normal for Typha to be unbalanced. Typha can handle hundreds of connections so it is of no concern if all nodes in a 10-node cluster (for example) connect to the same Typha. |
-| Threshold breach symptoms | Felix is not getting updates from Typha. $[prodname] network policies are out-of-sync. |
-| Threshold breach recommendations | Check Typha and Felix logs, and rollout restart Typha(s) if needed. |
-| Priority level | Recommended. |
-
-### Rebalanced client connections
-
-| Rebalanced client connections | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | rate(typha_connections_dropped\{$_rate_interval\}) |
-| Example value | \{endpoint="metrics-port", instance="10.0.1.20:9093", job="typha-metrics-svc", namespace="calico-system", pod="calico-typha-6c6cc9fcf7-csbdl", service="typha-metrics-svc"\} |
-| Explanation | Number of client connections dropped to rebalance and share the load across different Typhas. |
-| Threshold value recommendation | It is normal to see this value increasing sometimes. Investigate if connection dropped counters is rising constantly. If all Typhas are dropping connections because all Typhas believe they have too much load, this also warrants investigation. |
-| Threshold breach symptoms | Dropping connections is rate limited so it should not affect the cluster as a whole. Typha clients, like Felix, will get dropped sometimes (but not constantly), and could result in periodic delays to policy updates. |
-| Threshold breach recommendations | Ensure that the Kubernetes nodes have enough resources. |
-| Priority level | Optional. |
-
-### 99 percentile client fall-behind
-
-| 99 percentile client fall-behind | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | max by (instance) (typha_client_latency_secs\{quantile='0.99'\}) |
-| Example value | \{instance="10.0.1.20:9093"\} 0.1234\{instance="10.0.1.31:9093"\} 0.1234 |
-| Explanation | This metric measures how far behind Typha's client-handling threads are at reading updates.This metric will increase if:a) The client (e.g Felix) is slow or overloaded and cannot keep up with what Typha is sending or
b) Typha is overloaded and it cannot keep up with writes to all its clients.
This metric is a good indication of your cluster, Felix, and Typha health. | -| Threshold value recommendation | It is normal for this to spike when new clients connect; they must download and process the snapshot, during which time they will fall slightly behind. Investigate of latency persists. | -| Threshold breach symptoms | Typha clients receiving updates from Typha will be behind in time. Potential symptoms could include $[prodname] network policies being out-of-sync. | -| Threshold breach recommendations | Check Typha and Felix logs and resource usage. It is recommended to focus on Felix logs and resource usage first, as there is generally more overhead with Felix and thus more of a chance of overload. Rollout restart Typha(s) and calico-node(s) if needed. | -| Priority level | Recommended. | - -### 99 percentile client write latency - -| 99 percentile client write latency | | -| ---------------------------------- | ------------------------------------------------------------ | -| Metric |
max by (instance) (typha_client_write_latency_secs) |
-| Example value | \{instance="10.0.1.20:9093"\} 0.007450815 |
-| Explanation | Time for Typha to write to a client's socket (for example, Felix). |
-| Threshold value recommendation | If the write latency is increasing, this indicates that a client (for example, Felix) is having an issue, or the network is having an issue. It is normal for intermittent spikes. Investigate any persistent latency. |
-| Threshold breach symptoms | Typha clients will lag behind in receiving updates that Typha is sending. Potential symptoms include $[prodname] network policies being out-of-sync. |
-| Threshold breach recommendations | Check Felix logs and resource usage. |
-| Priority level | Recommended. |
-
-### 99 percentile client ping latency
-
-| 99 percentile client ping latency | |
-| --------------------------------- | ------------------------------------------------------------ |
-| Metric | max by (instance) (typha_ping_latency\{quantile="0.99"\}) |
-| Example value | \{instance="10.0.1.20:9093"\} 0.034285331 |
-| Explanation | This metric tracks the round-trip-time from Typha to a client. How long it takes for Typha's clients to respond to pings over the Typha protocol. |
-| Threshold value recommendation | An increase in this metric above 1 second indicates that the clients, network or Typha are more heavily loaded. It is normal for intermittent spikes. Persistent latency above 1 second warrants investigation. |
-| Threshold breach symptoms | Typha clients could be behind in time on updates Typha is sending. Potential symptoms include $[prodname] network policies being out-of-sync. |
-| Threshold breach recommendations | Check Typha and Felix logs and resource usage. It is recommended to focus on Felix logs and resource usage first, as there is generally more overhead with Felix and thus more of a chance of overload. Check if the node is overloaded and review/increase calico-node/Typha CPU requests if needed. If needed, rollout restart Typha(s) and calico-node(s). |
-| Priority level | Recommended. |
-
-## Typha cache internals
-
-### 99 percentile breadcrumb size
-
-| 99 percentile breadcrumb size | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | max by (instance) (typha_breadcrumb_size\{quantile="0.99"\}) |
-| Explanation | Typha stores datastore changes as a series of blocks called breadcrumbs. Typha will store updates inside of these breadcrumbs (for example if a pod churned, this would be a single update). Typha can store multiple updates in a single breadcrumb with the default maximum size number being 100. |
-| Threshold value recommendation | Typha generating blocks of size 100 during start up is normal. Investigate if Typha is consistently generating blocks of size 90+, which can indicate Typha is overloaded. |
-| Threshold breach symptoms | Maintained block of sizes of 100 can indicate that Typha is falling behind on information and updates contained in the datastore. This will lead to Typha clients also falling behind (for example, $[prodname] network policy object may not be current). |
-| Threshold breach recommendations | Check Typha logs and resource usage. Check if there is a lot of activity within the cluster that would cause Typha to send large breadcrumbs (for example, a huge amount of pod churn). If possible, reduce churn rate of resources on the cluster. |
-| Priority level | Recommended. |
-
-### Non-blocking breadcrumbs fraction
-
-| Non-blocking breadcrumb fraction | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | (sum by (instance) (rate(typha_breadcrumb_non_block\{30s\})))/((sum by (instance) (rate(typha_breadcrumb_non_block\{30s\})))+(sum by (instance) (rate(typha_breadcrumb_block\{30s\})))) |
-| Example value | \{instance="10.0.1.20:9093"\} NaN |
-| Explanation | Typha stores datastore changes as a series of blocks called "breadcrumbs". Each client "follows the breadcrumbs" either by blocking and waiting, or skipping to the next one (non-blocking) if it is already available. Non-blocking breadcrumb actions indicates that Typha is constantly sending breadcrumbs to keep up with the datastore. Blocking breadcrumb actions indicate that Typha and the client have caught up, are up-to-date, and are waiting on the next breadcrumb. This metric will give a ratio between blocking and non-blocking actions that can indicate the health of Typha, its clients, and the cluster. |
-| Threshold value recommendation | As the load on Typha increases, the ratio of skip-ahead, non-blocking reads, increases. If it approaches 100% then Typha may be overloaded (since clients only do non-blocking reads when they're behind). |
-| Threshold breach symptoms | Consistent non-blocking breadcrumbs could indicate that Typha is falling behind on information and updates contained in the datastore. This will lead to Typha clients also being behind (for example, $[prodname] network policy object may not be current). |
-| Threshold breach recommendations | Check Typha and Felix logs and resource usage. Check if there is a lot of activity within the cluster that would cause Typha to continuously send non-blocking breadcrumbs. |
-| Priority level | Recommended. |
-
-### Datastore updates total
-
-| Datastore updates total | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum by (instance) (rate(typha_updates_total\{30s\})) |
-| Example value | \{instance="10.0.1.20:9093"\} 0 |
-| Explanation | The rate of updates from the datastore(s). For example, updates to Pods/Nodes/Policies/etc. |
-| Threshold value recommendation | Intermittent spikes are expected. Constant updates indicates a very busy cluster (for example, lots of pod churn). |
-| Threshold breach symptoms | Constant updates could lead to overloaded Typhas whereTyphas clients could fall behind. |
-| Threshold breach recommendations | Ensure Typha has enough resources to handle a very dynamic cluster. |
-| Priority level | Optional. |
-
-### Datastore update skipped (no-ops)
-
-| Datastore update skipped (no-ops) | |
-| --------------------------------- | ------------------------------------------------------------ |
-| Metric | sum by (instance) (rate(typha_updates_skipped\{30s\})) |
-| Example value | \{instance="10.0.1.20:9093"\} 0 |
-| Explanation | The number of updates from the datastore that Typha detected were no-ops. For example, an update to a Kubernetes node resource that did not touch any values that is of interest to $[prodname]. Such updates are not propagated to clients, which saves resources. |
-| Threshold value recommendation | N/A |
-| Threshold breach symptoms | N/A |
-| Threshold breach recommendations | N/A |
-| Priority level | Optional. |
-
-## Typha snapshot details
-
-### Snapshot send time
-
-| Median snapshot send time | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | max by (instance) (typha_client_snapshot_send_secs\{quantile="0.5"\}) |
-| Example value | \{instance="10.0.1.20:9093"\} NaN |
-| Explanation | The median time to stream the initial datastore snapshot to each client. It is useful to know the time it takes for a client to receive the data when it connects; it does not include time to process the data. |
-| Threshold value recommendation | Investigate if this value is moving towards 10s of seconds. |
-| Threshold breach symptoms | High values of this metric could indicate that newly-started clients are taking a long time to get the latest snapshot of the datastore, increasing the window of time where networking/policy updates are not being applied to the dataplane during a restart/upgrade. Typha has a write timeout for writing the snapshot; if a client cannot receive the snapshot within that timeout, it is disconnected. Clients falling behind on information and updates contained in the datastore (for example, $[prodname] network policy object may not be current). |
-| Threshold breach recommendations | Check Typha and calico-node logs and resource usage. Check for network congestion. Investigate why a particular calico-node is slow; it is likely on an overloaded node with insufficient CPU). |
-| Priority level | Optional. |
-
-### Clients requiring grace period
-
-| Clients requiring grace period | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum by (instance) (typha_connections_grace_used) |
-| Example value | \{instance="10.0.1.20:9093"\} 0 |
-| Explanation | The number of Typhas with clients that required a grace period. After sending the snapshot to the client, Typha allows a grace period for the client to catch up to the most recent data. Typha sending the initial snapshot should take < 1 second, but the processing of the snapshot could take longer, so this grace period is there to allow the newly connected client to process the snapshot. |
-| Threshold value recommendation | If this metric is constantly increasing, it can indicate potential performance issues with Typha and clients. It can indicate that performance is being impacted and may warrant investigation. |
-| Threshold breach symptoms | High values of this metric could indicate clients falling behind on information and updates contained in the datastore (for example, $[prodname] network policy object may not be current). |
-| Threshold breach recommendations | Check Typha and calico-node logs and resource usage. Check for network congestion, and determine the root cause. |
-| Priority level | Optional. |
-
-### Max snapshot size (raw)
-
-| Max snapshot size (raw) | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | max(typha_snapshot_raw_bytes) |
-| Example value | \{\} 557359 |
-| Explanation | The raw size in bytes of snapshots sent from Typha to clients. |
-| Threshold value recommendation | N/A |
-| Threshold breach symptoms | N/A |
-| Threshold breach recommendations | N/A |
-| Priority Level | Optional. |
-
-### Max snapshot size (compressed)
-
-| Max snapshot size (compressed) | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | max(typha_snapshot_compressed_bytes) |
-| Example value | \{\}134845 |
-| Explanation | The compressed size in bytes of snapshots sent from Typha to clients. |
-| Threshold value recommendation | This metric can be helpful for customers to estimate the bandwidth requirements for Felix to startup. For example, if the compressed snapshot size is 20MB in size on average, and 1000 Felix/calico-nodes start up, the bandwidth requirements could be estimated at 20GB between the pool of Typha and the set of Felixes across the network. |
-| Threshold breach symptoms | N/A |
-| Threshold breach recommendations | N/A |
-| Priority Level | Optional. |
-
-## Policy metrics
-
-:::note
-The following policy metrics are a separate endpoint exposed by Felix that are used in Manager UI. They require special Prometheus configuration to scrape the metrics. For details, see [Policy metrics](./policy-metrics).
-
-:::
-
-### Denied traffic
-
-| Denied traffic | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | calico_denied_packets
calico_denied_bytes |
-| Example value | calico_denied_packets\{endpoint="calico-metrics-port", instance="ip-10-0-1-30.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-6pcqm", policy="default |
-| Explanation | Number of packets or bytes that have been dropped by explicit or implicit deny rules. Note that you'll get one instance of `calico_denied_packets/bytes` for each policy rule that is denying traffic. For example: calico_denied_packets\{policy="tier1\|fv/policy1\|0\|deny\|-1",scrIP="10.245.13.133"\} |
-| Threshold value recommendation | The general rule of thumb is this metric should report zero at a stable state. Any deviation means that policy and traffic have diverged. Achieving a zero state depends on the stability and maturity of your cluster and policy. |
-| Threshold breach symptoms | Either unexpected traffic is being denied because of an attack (one example), or expected traffic is being denied because of a misconfiguration in a policy. |
-| Threshold breach recommendations | If this metric indicates that policy and traffic have diverged, the recommended steps are: Determine if an attack is causing the metric to spike, or if these flows should be allowed. If the flow should indeed be allowed, update the policy or a preceding policy to allow this traffic. |
-| Priority level | Recommended. |
-
-### Traffic per rule
-
-| Traffic per rule | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | cnx_policy_rule_bytescnx_policy_rule_packets |
-| Example value | cnx_policy_rule_bytes\{action="allow", endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="1", service="calico-node-metrics", tier="allow-tigera", traffic_direction="inbound"\} |
-| Explanation | Number of bytes or packets handled by $[prodname] network policy rules. |
-| Threshold value recommendation | This metric should usually be non-zero (unless expected). A zero value indicates the rule is not matching any packets, and could be surplus to requirements. |
-| Threshold breach symptoms | N/A |
-| Threshold breach recommendations | If this metrics consistently reports a zero value over an acceptable period of time, you can consider removing the policy rule. |
-| Priority Level | Optional. |
-
-### Connections per policy rule
-
-| Connections per policy rule | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | cnx_policy_rule_connections |
-| Example value | cnx_policy_rule_connections\{endpoint="calico-metrics-port", instance="ip-10-0-1-20.ca-central-1.compute.internal", job="calico-node-metrics", namespace="calico-system", pod="calico-node-qzpkt", policy="es-kube-controller-access", rule_direction="egress", rule_index="0", service="calico-node-metrics", tier="allow-tigera", traffic_direction="outbound"\} |
-| Explanation | Number connections handled by $[prodname] policy rules. |
-| Threshold value recommendation | This metric is similar to *Traffic per Rule* but this deals more with flow monitoring. This metric should usually be non-zero. A zero value indicates that the rule is not matching any packets and could be surplus to requirements. |
-| Threshold breach symptoms | N/A |
-| Threshold breach recommendations | If this metrics consistently reports a zero value over an acceptable period of time, this policy rule can be considered for removal. |
-| Priority Level | Optional. |
-## Felix cluster-state metrics
-
-### CPU usage
-
-| CPU usage | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | rate(process_cpu_seconds_total\{30s\}) \* 100 |
-| Example value | \{endpoint="metrics-port", instance="10.0.1.20:9091", job="felix-metrics-svc", namespace="calico-system", pod="calico-node-qzpkt", service="felix-metrics-svc"\}3.1197504199664072 |
-| Explanation | CPU in use by calico-node represented as a percentage of a core. |
-| Threshold value recommendation | A spike at startup is normal. It is recommended to first achieve a baseline and then monitor for any unexpected increases from this baseline. Investigate if maintained CPU usage goes above 90%. |
-| Threshold breach symptoms | Unexpected maintained CPU usage could cause Felix to fall behind and could cause delays to policy updates. |
-| Threshold breach recommendations | Check CPU usage on Kubernetes nodes. Increase resources if needed, rollout restart calico-node(s) if needed. |
-| Priority level | Recommended. |
-
-### Memory usage
-
-| Memory usage | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | process_resident_memory_bytes |
-| Example value | process_resident_memory_bytes\{endpoint="metrics-port", instance="10.0.1.20:9091", job="felix-metrics-svc", namespace="calico-system", pod="calico-node-qzpkt", service="felix-metrics-svc"\} 98996224 |
-| Explanation | Amount of memory in use by calico-node. |
-| Threshold value recommendation | Recommended to achieve a baseline first, then monitor for any unexpected increases from this baseline. Investigate if maintained CPU usage goes above 90% of what is available from the underlying node. |
-| Threshold breach symptoms | Unexpected, maintained, memory usage could cause Felix to fall behind and could cause delays to policy updates. |
-| Threshold breach recommendations | Check memory usage on Kubernetes nodes. Increase resources if needed, rollout restart typha(s) if needed. |
-| Priority level | Recommended. |
-
-### Active hosts on each endpoint
-
-| Active hosts on each endpoint | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | felix_active_local_endpoints |
-| Example value | felix_active_local_endpoints\{endpoint="metrics-port", instance="10.0.1.30:9091", job="felix-metrics-svc", namespace="calico-system", pod="calico-node-6pcqm", service="felix-metrics-svc"\} 36 |
-| Explanation | Number of active pod-networked pods, and HEPs, on this node. |
-| Threshold value recommendation | Threshold relates to resource limits on the node for example kubelet's max pods setting. |
-| Threshold breach symptoms | Suggests Felix is getting out of sync. |
-| Threshold breach recommendations | Rolling restart calico-node and report issue to support. |
-| Priority level | Optional. |
-
-### Active calico nodes
-
-| Active calico nodes | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | max(felix_cluster_num_hosts) |
-| Example value | \{\} 3 |
-| Explanation | Total number of nodes in the cluster that have calico-node deployed and running. |
-| Threshold value recommendation | This value should be equal to the number of nodes in the cluster. If there are discrepancies, then calico-nodes on some nodes are having issues. |
-| Threshold breach symptoms | $[prodname] network policies on affected nodes could be out-of-sync. |
-| Threshold breach recommendations | Check calico-node logs, rollout restart calico-node if needed. |
-| Priority level | Recommended. |
-
-### Felix cluster policies
-
-| Felix cluster policies | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | felix_cluster_num_policies |
-| Example value | felix_cluster_num_policies\{endpoint="metrics-port", instance="10.0.1.20:9091", job="felix-metrics-svc", namespace="calico-system", pod="calico-node-qzpkt", service="felix-metrics-svc"\} 58 |
-| Explanation | Total number of $[prodname] network policies in the cluster. |
-| Threshold value recommendation | Because $[prodname] is a distributed system, the number of policies should be generally consistent across all nodes. It is expected to have some skew between nodes for a short period of time while they sync, however they should never be out of sync for very long. |
-| Threshold breach symptoms | If nodes are out of sync for long time, calico-nodes may be having issues or experiencing resource contention. Check the Errors Plot to see if there are any iptables errors reported. |
-| Threshold breach recommendations | Redeploy calico-node if issues are seen, and increase resources if needed. |
-| Priority level | Optional. |
-
-### Felix active local policies
-
-| Felix active local policies | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | felix_active_local_policies |
-| Example value | felix_active_local_policies\{endpoint="metrics-port", instance="10.0.1.30:9091", job="felix-metrics-svc", namespace="calico-system", pod="calico-node-6pcqm", service="felix-metrics-svc"\} 44 |
-| Explanation | Total number of network policies deployed on per node basis. |
-| Threshold value recommendation | There is no hard limit to active policies. We can handle 1000+ active policies, but it impacts performance, especially if there's pod churn. The best solution is to optimize policies by combining multiple rules into one policy, and make sure that top-level policy selectors are being used. |
-| Threshold breach symptoms | N/A |
-| Threshold breach recommendations | Redeploy calico-node if issues are seen, and increase resources if needed. |
-| Priority level | Recommended. |
-
-### Felix open FDS
-
-| Felix open FDS | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum by (pod) (process_open_fds\{pod=~"calico-node.*"\}) |
-| Example value | \{pod="calico-node-6pcqm"\} 90 |
-| Explanation | Number of opened file descriptors per calico-node pod. |
-| Threshold value recommendation | Alert on this metric when it approaches the ulimit (as reported in `process_max_fds` value). You should not be anywhere near the maximum. |
-| Threshold breach symptoms | Felix may become unstable/crash or fail to apply updates as it should. These failures and issues are logged. |
-| Threshold breach recommendations | Check Felix logs, redeploy calico-node if you see log issues, and increase `max_fds value` if possible. |
-| Priority Level | Optional. |
-
-### Felix max FDS
-
-| Felix max FDS | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum by (pod) (process_max_fds\{pod=~"calico-node.*"\}) |
-| Example value | \{pod="calico-node-qzpkt"\} 1048576 |
-| Explanation | Maximum number of opened file descriptors allowed per calico-node pod. |
-| Threshold value recommendation | N/A |
-| Threshold breach symptoms | N/A |
-| Threshold breach recommendations | N/A |
-| Priority level | Optional. |
-
-### Felix resync started
-
-| Felix resync started | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum(rate(felix_resyncs_started\{5m\})) |
-| Explanation | This is the number of times that Typha has reported to Felix that it is re-connecting with the datastore. |
-| Threshold value recommendation | Occasional resyncs are normal. Investigate resync counters that rapidly rise. |
-| Threshold breach symptoms | Typha pods may be having issues or experiencing resource contention. Some calico-nodes that are paired with Typha pods experiencing issues will not be able to sync with the datastore. |
-| Threshold breach recommendations | Investigate the root cause to avoid redeploying Typha (which can be very disruptive). Check resource contention and network connectivity from Typha to the datastore to see if Typha is working fine or if the API server is overloaded. |
-| Priority level | Recommended. |
-
-### Felix dropped logs
-
-| Felix dropped logs | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | felix_logs_dropped |
-| Example value | felix_logs_dropped\{endpoint="metrics-port", instance="10.0.1.20:9091", job="felix-metrics-svc", namespace="calico-system", pod="calico-node-qzpkt", service="felix-metrics-svc"\} 0 |
-| Explanation | The number of logs Felix has dropped. Note that this metric does not count flow-logs; it counts logs to stdout. |
-| Threshold value recommendation | Occasional drops are normal. Investigate if drop counters rapidly rise. |
-| Threshold breach symptoms | Felix will drop logs if it cannot keep up with writing them out. These are ordinary code logs, not flow logs. Calico-node may be under resource constraints. |
-| Threshold breach recommendations | Check CPU usage on calico-nodes and Kubernetes nodes. Increase resources if needed, and rollout restart calico-node(s) if needed. |
-| Priority level | Optional. |
-
-## Felix error metrics
-
-### IPset errors
-
-| IPset errors | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum(rate(felix_ipset_errors\{5m\})) |
-| Example value | \{\} 0 |
-| Explanation | Number of ipset creation, modification, and deletion command failures. This metric reports how many times the ipset command has failed when Felix tried to run it. An error can occur when Felix sends bad ipset command data, or the kernel throws an error (potentially because it was too busy to handle this request at that time). |
-| Threshold value recommendation | Occasional errors are normal. Investigate error counters that rapidly rise. |
-| Threshold breach symptoms | $[prodname] network policies may not scope all endpoints in network policy rules. Cluster nodes may be under resource contention, which may result in other _error and _seconds metrics rising. Repeated errors could mean some persistent problem (for example, some other process has created an IP set with that name, which is incompatible). |
-| Threshold breach recommendations | See the Errors Plot graph to determine if the scope is cluster-wide or node-local. Check calico-node logs. Check resource usage and contention on Kubernetes nodes and calico-nodes. Add nodes/resources if needed. If resource contention is not seen, restart calico-node(s) and monitor. Ensure that other process using IPtables are not blocking $[prodname] network policy management. |
-| Priority level | Optional. |
-
-### Iptables restore errors
-
-| Iptables restore errors | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum(rate(felix_iptables_restore_errors\{5m\})) |
-| Explanation | The number of iptables-restore errors over five minutes. The iptables-restore command is used when $[prodname] makes a change to iptables. For example, a new WEP or HEP is created, changes to a WEP or HEP or a change to a policy that affects a WEP or HEP. |
-| Threshold value recommendation | Occasional errors are normal. Investigate error counters that rapidly rise. |
-| Threshold breach symptoms | $[prodname] network policies are not up to date. Cluster nodes may be under resource contention, which may result in other _error and _seconds metrics rising. |
-| Threshold breach recommendations | See the Errors Plot graph to determine if the scope is cluster-wide or node-local. Check calico-node logs. Check resource usage and contention on Kubernetes nodes and calico-nodes. Add nodes/resources if needed. If no resource contention is seen, restart calico-node and monitor. |
-| Priority level | Optional. |
-
-### Iptables save errors
-
-| Iptables save errors | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum(rate(felix_iptables_save_errors\{5m\})) |
-| Example value | \{\} 0 |
-| Explanation | Number of iptables-save errors. The iptables-save command is run before every iptables-restore command so that $[prodname] has the current state of iptables. |
-| Threshold value recommendation | Occasional errors are normal. Investigate error counters that rapidly rise. |
-| Threshold breach symptoms | $[prodname] network policies are not up to date. Cluster nodes may be under resource contention, which may result in other _error and _seconds metrics rising. Repeated errors could mean some persistent problem (for example, some other process has creating iptables rules that $[prodname] cannot decode with the version of iptables-save in use). |
-| Threshold breach recommendations | See the Errors Plot graph to determine if the scope is cluster-wide or node-local. Check calico-node logs. Check resource usage and contention on Kubernetes nodes and calico-nodes. Add nodes/resources if needed. If no resource contention is seen, restart calico-node and monitor. |
-| Priority level | Optional. |
-
-### Felix log errors
-
-| Felix log errors | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | sum(rate(felix_log_errors\{5m\})) |
-| Example value | \{\} 0 |
-| Explanation | The number of times Felix fails to write out a log because the log buffer is full. |
-| Threshold value recommendation | Occasional errors are normal. Investigate error counters that rapidly rise. |
-| Threshold breach symptoms | Calico-node may be under resource contention, which may result in other _error and _seconds metrics rising. |
-| Threshold breach recommendations | See the Errors Plot graph to determine if the scope is cluster-wide or node-local. Check resource usage and contention on Kubernetes nodes and calico-nodes. Add nodes/resources if needed. If no resource contention is seen, restart calico-node and monitor. |
-| Priority level | Optional. |
-
-### Monitor Felix metrics using a graph
-
-| Errors plot graph | |
-| -------------------------------- | ------------------------------------------------------------ |
-| Metric | rate(felix_ipset_errors\{5m\}) \|\| rate(felix_iptables_restore_errors[5m]) \|\| rate(felix_iptables_save_errors[5m]) \|\| rate(felix_log_errors\{5m\}) |
-| Example value | \{endpoint="metrics-port", instance="10.0.1.20:9091", job="felix-metrics-svc", namespace="calico-system", pod="calico-node-qzpkt", service="felix-metrics-svc"\} 0 |
-| Explanation | Checks if there have been any iptables-save, iptables-restore, or ipset command errors in the past five minutes. Keeps track of what node is reporting which error. |
-| Threshold value recommendation | Occasional errors are normal. Investigate error counters that rapidly rise. For this specific metric it is worth focusing on the metric that is spiking, and referencing that metric information. |
-| Threshold breach symptoms | Dependent on the specific metric that is logging errors. |
-| Threshold breach recommendations | If more than one metric is rising, check if all rising metrics are related to a specific calico-node. If this is the case, then the issue is local to that calico-node. Check calico-node logs. Check resource usage for the node and calico-node pod. If more than one metric is rising rapidly across all calico-nodes, then it is a cluster-wide issue and cluster health must be checked. Check cluster resource usage, cluster networking/infrastructure health, and restart calico-nodes and calico-typha pods. |
-| Priority level | Recommended. |
-
-## Felix time-based metrics
-
-### Dataplane apply time quantile 0.5/0.9/0.99
-
-| Dataplane apply time quantile 0.5/0.9/0.99 | |
-| ------------------------------------------ | ------------------------------------------------------------ |
-| Metric | felix_int_dataplane_apply_time_seconds\{quantile="0.5"\}felix_int_dataplane_apply_time_seconds\{quantile="0.9"\}felix_int_dataplane_apply_time_seconds\{quantile="0.99"\} |
-| Example value | felix_int_dataplane_apply_time_seconds\{quantile="0.5"\}:felix_int_dataplane_apply_time_seconds\{endpoint="metrics-port", instance="10.0.1.30:9091", job="felix-metrics-svc", namespace="calico-system", pod="calico-node-6pcqm", quantile="0.5", service="felix-metrics-svc"\} 0.020859218 |
-| Explanation | Time in seconds that it took to apply a dataplane update ,viewed at the median, 90th percentile, and 99th percentile. |
-| Threshold value recommendation | Thresholds will vary depending on cluster size and rate of churn. It is recommended that a baseline be set to determine a normal threshold value. In the field we have seen >10s in extremely high-scale clusters with 100k+ endpoints and lots of policy/Kubernetes services. |
-| Threshold breach symptoms | Large time-to-apply values will cause a delay between $[prodname] network policy commits and enforcement in the dataplane. This is dependent on how $[prodname] waiting for kube-proxy to release the iptables lock, which is influenced by the number of services in use. |
-| Threshold breach recommendations | Increase cluster resources, and reduce the number of Kubernetes services if possible. |
-| Priority level | Recommended. |
-
-### Felix route table list seconds quantile 0.5/0.9/0.99
-
-| Felix route table list seconds quantile 0.5/0.9/0.99 | |
-| ---------------------------------------------------- | ------------------------------------------------------------ |
-| Metric | felix_route_table_list_seconds\{quantile="0.5"\}felix_route_table_list_seconds\{quantile="0.9"\}felix_route_table_list_seconds\{quantile="0.99"\} |
-| Example value | felix_route_table_list_seconds\{quantile="0.5"\}:felix_route_table_list_seconds\{endpoint="metrics-port",instance="10.0.1.30:9091",job="felix-metrics-svc",namespace="calico-system", pod="calico-node-6pcqm",quantile="0.5", service="felix-metrics-svc"\} 0.000860426 |
-| Explanation | Time to list all the interfaces during a resync, viewed at the median, 90th percentile and 99th percentile. |
-| Threshold value recommendation | Thresholds will vary depending on the number of cali interfaces per node. It is recommended that a baseline be set to determine a normal threshold value. |
-| Threshold breach symptoms | High values indicate high CPU usage in felix and slow dataplane updates. |
-| Threshold breach recommendations | Increase cluster resources. Reduce the number of cali interfaces per node where possible. |
-| Priority level | Optional. |
-
-### Felix graph update time quantile 0.5/0.9/0/99
-
-| Felix graph update time seconds quantile 0.5/0.9/0.99 | |
-| ----------------------------------------------------- | ------------------------------------------------------------ |
-| Metric | felix_calc_graph_update_time_seconds\{quantile="0.5"\}felix_calc_graph_update_time_seconds\{quantile="0.9"\}felix_calc_graph_update_time_seconds\{quantile="0.99"\} |
-| Example value | felix_calc_graph_update_time_seconds\{quantile="0.5"\}:felix_calc_graph_update_time_seconds\{endpoint="metrics-port",instance="10.0.1.30:9091", job="felix-metrics-svc",namespace="calico-system", pod="calico-node-6pcqm",quantile="0.5", service="felix-metrics-svc"\} 0.00007129 |
-| Explanation | This metric reports the time taken to update the calculation graph for each datastore on an update call, viewed at the median, 90th percentile and 99th percentile. The calculation graph is the Felix component that takes all the policies/workload endpoints/host endpoints information that it has received from Typha, and distills it down to dataplane updates that are relevant for this node. |
-| Threshold value recommendation | After *start of day* (where we will typically get a large update), then values should be sub 1 second (with occasional blips to 1+ seconds). Should be measured in milliseconds with the occasional blip to a second or two. Investigate if the result is constantly in values of seconds. |
-| Threshold breach symptoms | High values indicate high CPU usage in felix and slow dataplane updates. |
-| Threshold breach recommendations | Increase cluster resources. Check calico-node logs. Rollout restart calico-node(s) if needed. |
-| Priority level | Recommended. |
diff --git a/calico-cloud_versioned_docs/version-20-1/operations/monitor/prometheus/alertmanager.mdx b/calico-cloud_versioned_docs/version-20-1/operations/monitor/prometheus/alertmanager.mdx
deleted file mode 100644
index 7215bf68dc..0000000000
--- a/calico-cloud_versioned_docs/version-20-1/operations/monitor/prometheus/alertmanager.mdx
+++ /dev/null
@@ -1,103 +0,0 @@
----
-description: Configure Alertmanager, a Prometheus feature that routes alerts.
----
-
-# Configure Alertmanager
-
-Alertmanager is used by $[prodname] to route alerts from Prometheus to the administrators.
-It handles routing, deduplicating, grouping, silencing and inhibition of alerts.
-
-More detailed information about Alertmanager is available in the [upstream documentation](https://prometheus.io/docs/alerting/configuration).
-
-### Updating the AlertManager config
-
-- Save the current alertmanager secret, usually named `alertmanager-| Project | -Artifact Name | -LICENSE | -
|---|---|---|
| abbrev | -abbrev-1.1.1.tgz | -ISC | -
| algoliasearch | -algoliasearch.umd-4.2.0.js | -MIT | -
| ansi-regex | -ansi-regex-2.1.1.tgz | -MIT | -
| ansi-styles | -ansi-styles-3.2.1.tgz | -MIT | -
| @types/anymatch | -anymatch-1.3.1.tgz | -MIT | -
| app-policy | -app-policy-v3.16.6 | -Tigera Proprietary | -
| argparse | -argparse-1.0.9.tgz | -MIT | -
| arr-diff | -arr-diff-4.0.0.tgz | -MIT | -
| arr-flatten | -arr-flatten-1.1.0.tgz | -MIT | -
| arr-union | -arr-union-3.1.0.tgz | -MIT | -
| array-unique | -array-unique-0.3.2.tgz | -MIT | -
| asap | -asap-2.0.6.tgz | -MIT | -
| assign-symbols | -assign-symbols-1.0.0.tgz | -MIT | -
| atob | -atob-2.1.2.tgz | -Apache 2.0 | -
| atomicwrites | -atomicwrites-1.4.0-py2.py3-none-any.whl | -MIT | -
| attrs | -attrs-20.3.0-py2.py3-none-any.whl | -MIT | -
| avsdf-base | -avsdf-base-1.0.0.tgz | -MIT | -
| babel-standalone | -babel-6.26.0.min.js | -MIT | -
| babel-runtime | -babel-runtime-6.26.0.tgz | -MIT | -
| backports.functools-lru-cache | -backports.functools_lru_cache-1.6.1-py2.py3-none-any.whl | -MIT | -
| balanced-match | -balanced-match-0.4.2.tgz | -MIT | -
| balanced-match | -balanced-match-1.0.0.tgz | -MIT | -
| base | -base-0.11.2.tgz | -MIT | -
| beautifulsoup4 | -beautifulsoup4-4.9.3-py2-none-any.whl | -MIT | -
| big.js | -big.js-5.2.2.tgz | -MIT | -
| boolbase | -boolbase-1.0.0.tgz | -ISC | -
| twitter-bootstrap | -bootstrap-3.3.7.min.js | -MIT | -
| bootstrap | -bootstrap-3.4.1.tgz | -MIT | -
| brace-expansion | -brace-expansion-1.1.11.tgz | -MIT | -
| braces | -braces-2.3.2.tgz | -MIT | -
| bs4 | -bs4-0.0.1.tar.gz | -MIT | -
| buffer-from | -buffer-from-1.1.1.tgz | -MIT | -
| cache-base | -cache-base-1.0.1.tgz | -MIT | -
| cachetools | -cachetools-3.1.1-py2.py3-none-any.whl | -MIT | -
| projectcalico | -calico-v3.17.1 | -Apache 2.0 | -
| projectcalico | -calicoctl-v3.17.1 | -Apache 2.0 | -
| camel-case | -camel-case-4.1.1.tgz | -MIT | -
| certifi | -certifi-2020.12.5-py2.py3-none-any.whl | -Mozilla 2.0 | -
| chain-function | -chain-function-1.0.0.tgz | -MIT | -
| chalk | -chalk-2.4.2.tgz | -MIT | -
| chardet | -chardet-3.0.4-py2.py3-none-any.whl | -LGPL 3.0 | -
| chardet | -chardet-4.0.0-py2.py3-none-any.whl | -LGPL 3.0 | -
| chevrotain | -chevrotain-6.5.0.tgz | -Apache 2.0 | -
| cidr-regex | -cidr-regex-2.0.10.tgz | -BSD 2 | -
| class-transformer | -class-transformer-0.3.1.tgz | -MIT | -
| class-utils | -class-utils-0.3.6.tgz | -MIT | -
| class-validator | -class-validator-0.9.1.tgz | -MIT | -
| classnames | -classnames-2.2.5.tgz | -MIT | -
| classnames | -classnames-2.2.6.tgz | -MIT | -
| clean-css | -clean-css-4.2.3.tgz | -MIT | -
| clipboard.js | -clipboard-2.0.0.min.js | -MIT | -
| cni-plugin | -cni-plugin-v3.16.6 | -Tigera Proprietary | -
| @babel/code-frame | -code-frame-7.10.1.tgz | -MIT | -
| codemirror | -codemirror-5.57.0.js | -MIT | -
| codemirror | -codemirror-5.57.0.tgz | -MIT | -
| collection-visit | -collection-visit-1.0.0.tgz | -MIT | -
| color-convert | -color-convert-1.9.3.tgz | -MIT | -
| color-name | -color-name-1.1.3.tgz | -MIT | -
| commander | -commander-2.13.0.tgz | -MIT | -
| commander | -commander-2.20.3.tgz | -MIT | -
| commander | -commander-4.1.1.tgz | -MIT | -
| component-emitter | -component-emitter-1.3.0.tgz | -MIT | -
| concat-map | -concat-map-0.0.1.tgz | -MIT | -
| configparser | -configparser-4.0.2-py2.py3-none-any.whl | -MIT | -
| connected-react-router | -connected-react-router-6.5.2.tgz | -MIT | -
| contextlib2 | -contextlib2-0.6.0.post1-py2.py3-none-any.whl | -Python 2.0 | -
| copy-descriptor | -copy-descriptor-0.1.1.tgz | -MIT | -
| @popperjs/core | -core-2.4.4.tgz | -MIT | -
| core-js | -core-js-1.2.7.tgz | -MIT | -
| core-js | -core-js-2.5.1.tgz | -MIT | -
| core-js | -core-js-2.5.7.tgz | -MIT | -
| core-js | -core-js-3.6.5.tgz | -MIT | -
| cose-base | -cose-base-1.0.3.tgz | -MIT | -
| create-react-class | -create-react-class-15.6.2.tgz | -MIT | -
| css-box-model | -css-box-model-1.1.1.tgz | -MIT | -
| css-select | -css-select-1.2.0.tgz | -BSD 2 | -
| css-what | -css-what-2.1.3.tgz | -BSD 2 | -
| @ungap/custom-elements | -custom-elements-0.1.12.tgz | -ISC | -
| cytoscape | -cytoscape-3.15.2.tgz | -MIT | -
| cytoscape | -cytoscape-3.18.0.min.js | -MIT | -
| cytoscape-avsdf | -cytoscape-avsdf-1.0.0.tgz | -MIT | -
| cytoscape-cise | -cytoscape-cise-1.0.0.tgz | -MIT | -
| cytoscape-context-menus | -cytoscape-context-menus-4.0.0.tgz | -MIT | -
| cytoscape-cose-bilkent | -cytoscape-cose-bilkent-4.1.0.tgz | -MIT | -
| cytoscape-dagre-cluster-fix | -cytoscape-dagre-cluster-fix-2.2.5.tgz | -MIT | -
| cytoscape-expand-collapse | -cytoscape-expand-collapse-4.0.0.tgz | -MIT | -
| cytoscape-fcose | -cytoscape-fcose-1.2.3.tgz | -MIT | -
| cytoscape-layers | -cytoscape-layers-2.1.0.tgz | -MIT | -
| cytoscape-navigator | -cytoscape-navigator-2.0.1.tgz | -MIT | -
| cytoscape-popper | -cytoscape-popper-1.0.7.js | -MIT | -
| cytoscape-popper | -cytoscape-popper-1.0.7.tgz | -MIT | -
| d3 | -d3-5.5.0.tgz | -BSD 3 | -
| d3-array | -d3-array-1.2.1.tgz | -BSD 3 | -
| d3-array | -d3-array-1.2.4.tgz | -BSD 3 | -
| d3-axis | -d3-axis-1.0.8.tgz | -BSD 3 | -
| d3-brush | -d3-brush-1.0.4.tgz | -BSD 3 | -
| d3-chord | -d3-chord-1.0.4.tgz | -BSD 3 | -
| d3-collection | -d3-collection-1.0.4.tgz | -BSD 3 | -
| d3-collection | -d3-collection-1.0.7.tgz | -BSD 3 | -
| d3-color | -d3-color-1.0.3.tgz | -BSD 3 | -
| d3-contour | -d3-contour-1.2.0.tgz | -BSD 3 | -
| d3-dispatch | -d3-dispatch-1.0.3.tgz | -BSD 3 | -
| d3-drag | -d3-drag-1.2.1.tgz | -BSD 3 | -
| d3-dsv | -d3-dsv-1.0.8.tgz | -BSD 3 | -
| d3-ease | -d3-ease-1.0.3.tgz | -BSD 3 | -
| d3-fetch | -d3-fetch-1.1.0.tgz | -BSD 3 | -
| d3-force | -d3-force-1.1.0.tgz | -BSD 3 | -
| d3-format | -d3-format-1.2.2.tgz | -BSD 3 | -
| d3-geo | -d3-geo-1.10.0.tgz | -BSD 3 | -
| d3-hierarchy | -d3-hierarchy-1.1.6.tgz | -BSD 3 | -
| d3-interpolate | -d3-interpolate-1.1.6.tgz | -BSD 3 | -
| d3-interpolate | -d3-interpolate-1.3.2.tgz | -BSD 3 | -
| d3-path | -d3-path-1.0.5.tgz | -BSD 3 | -
| d3-polygon | -d3-polygon-1.0.3.tgz | -BSD 3 | -
| d3-quadtree | -d3-quadtree-1.0.3.tgz | -BSD 3 | -
| d3-random | -d3-random-1.1.0.tgz | -BSD 3 | -
| d3-sankey-circular | -d3-sankey-circular-0.34.0.tgz | -MIT | -
| d3-scale | -d3-scale-2.0.0.tgz | -BSD 3 | -
| d3-scale | -d3-scale-2.1.2.tgz | -BSD 3 | -
| d3-scale-chromatic | -d3-scale-chromatic-1.3.0.tgz | -BSD 3 | -
| d3-selection | -d3-selection-1.3.0.tgz | -BSD 3 | -
| d3-shape | -d3-shape-1.2.0.tgz | -BSD 3 | -
| d3-shape | -d3-shape-1.2.3.tgz | -BSD 3 | -
| d3-shape | -d3-shape-1.3.7.tgz | -BSD 3 | -
| d3-time | -d3-time-1.0.8.tgz | -BSD 3 | -
| d3-time-format | -d3-time-format-2.1.1.tgz | -BSD 3 | -
| d3-timer | -d3-timer-1.0.7.tgz | -BSD 3 | -
| d3-transition | -d3-transition-1.1.1.tgz | -BSD 3 | -
| d3-voronoi | -d3-voronoi-1.1.2.tgz | -BSD 3 | -
| d3-zoom | -d3-zoom-1.7.1.tgz | -BSD 3 | -
| dagre | -dagre-0.7.4.js | -MIT | -
| dagre-cluster-fix | -dagre-cluster-fix-0.9.3.tgz | -MIT | -
| debug | -debug-2.6.9.tgz | -MIT | -
| decimal.js-light | -decimal.js-light-2.5.0.tgz | -MIT | -
| decode-uri-component | -decode-uri-component-0.2.0.tgz | -MIT | -
| deepdiff | -deepdiff-3.3.0-py2-none-any.whl | -MIT | -
| deepmerge | -deepmerge-2.1.1.tgz | -MIT | -
| define-properties | -define-properties-1.1.2.tgz | -MIT | -
| define-properties | -define-properties-1.1.3.tgz | -MIT | -
| define-property | -define-property-0.2.5.tgz | -MIT | -
| define-property | -define-property-1.0.0.tgz | -MIT | -
| define-property | -define-property-2.0.2.tgz | -MIT | -
| diff | -diff-3.5.0.tgz | -BSD 3 | -
| diff2html | -diff2html-2.4.0.tgz | -MIT | -
| dom-converter | -dom-converter-0.2.0.tgz | -MIT | -
| dom-helpers | -dom-helpers-3.3.1.tgz | -MIT | -
| dom-helpers | -dom-helpers-3.4.0.tgz | -MIT | -
| dom-serializer | -dom-serializer-0.2.2.tgz | -MIT | -
| dom-walk | -dom-walk-0.1.2.tgz | -MIT | -
| domelementtype | -domelementtype-1.3.1.tgz | -BSD 2 | -
| domelementtype | -domelementtype-2.0.1.tgz | -BSD 2 | -
| domhandler | -domhandler-2.4.2.tgz | -BSD 2 | -
| domutils | -domutils-1.5.1.tgz | -BSD 2 | -
| domutils | -domutils-1.7.0.tgz | -BSD 2 | -
| dot-case | -dot-case-3.0.3.tgz | -MIT | -
| elasticsearch | -elasticsearch-6.8.1-py2.py3-none-any.whl | -Apache 2.0 | -
| elementary-circuits-directed-graph | -elementary-circuits-directed-graph-1.2.0.tgz | -MIT | -
| emojis-list | -emojis-list-3.0.0.tgz | -MIT | -
| encoding | -encoding-0.1.12.tgz | -MIT | -
| entities | -entities-1.1.2.tgz | -BSD 2 | -
| entities | -entities-2.0.3.tgz | -BSD 2 | -
| es-abstract | -es-abstract-1.17.5.tgz | -MIT | -
| es-to-primitive | -es-to-primitive-1.2.1.tgz | -MIT | -
| es5-shim | -es5-shim-4.3.1.js | -MIT | -
| escape-string-regexp | -escape-string-regexp-1.0.5.tgz | -MIT | -
| esprima | -esprima-4.0.0.tgz | -BSD 2 | -
| expand-brackets | -expand-brackets-2.1.4.tgz | -MIT | -
| extend-shallow | -extend-shallow-2.0.1.tgz | -MIT | -
| extend-shallow | -extend-shallow-3.0.2.tgz | -MIT | -
| extglob | -extglob-2.0.4.tgz | -MIT | -
| fast-levenshtein | -fast-levenshtein-2.0.6.tgz | -MIT | -
| fbjs | -fbjs-0.8.16.tgz | -MIT | -
| felix | -felix-v3.17.2 | -Tigera Proprietary | -
| file-saver | -file-saver-2.0.1.tgz | -MIT | -
| fill-range | -fill-range-4.0.0.tgz | -MIT | -
| @fortawesome/fontawesome-common-types | -fontawesome-common-types-0.2.32.tgz | -MIT | -
| @fortawesome/fontawesome-svg-core | -fontawesome-svg-core-1.2.10.tgz | -MIT | -
| for-in | -for-in-1.0.2.tgz | -MIT | -
| foreach | -foreach-2.0.5.tgz | -MIT | -
| fork-ts-checker-webpack-plugin | -fork-ts-checker-webpack-plugin-4.1.6.tgz | -MIT | -
| formik | -formik-2.1.3.tgz | -MIT | -
| fragment-cache | -fragment-cache-0.2.1.tgz | -MIT | -
| @fortawesome/free-brands-svg-icons | -free-brands-svg-icons-5.6.1.tgz | -CC BY 4.0 | -
| @fortawesome/free-regular-svg-icons | -free-regular-svg-icons-5.15.1.tgz | -CC BY 4.0 | -
| @fortawesome/free-solid-svg-icons | -free-solid-svg-icons-5.6.1.tgz | -CC BY 4.0 | -
| funcsigs | -funcsigs-1.0.2-py2.py3-none-any.whl | -Apache 2.0 | -
| function-bind | -function-bind-1.1.1.tgz | -MIT | -
| get-value | -get-value-2.0.6.tgz | -MIT | -
| github.com/alecthomas/participle | -github.com/alecthomas/participle-v0.3.0 | -MIT | -
| github.com/apparentlymart/go-cidr/cidr | -github.com/apparentlymart/go-cidr/cidr-v1.0.1 | -MIT | -
| github.com/aquasecurity/kube-bench/check | -github.com/aquasecurity/kube-bench/check-v0.0.34 | -Apache 2.0 | -
| github.com/araddon/dateparse | -github.com/araddon/dateparse-262228af701ebf3932b8b8488da6781b9d585c88 | -MIT | -
| github.com/avast/retry-go | -github.com/avast/retry-go-v2.2.0 | -MIT | -
| github.com/aws/aws-lambda-go/events | -github.com/aws/aws-lambda-go/events-v1.13.3 | -Apache 2.0 | -
| github.com/aws/aws-sdk-go/aws | -github.com/aws/aws-sdk-go/aws-v1.25.8 | -Apache 2.0 | -
| github.com/bmizerany/pat | -github.com/bmizerany/pat-6226ea591a40176dd3ff9cd8eff81ed6ca721a00 | -MIT | -
| github.com/bronze1man/gostrongswanvici | -github.com/bronze1man/gostrongswanvici-27d02f80ba4008de552efb746b3f6eaa7718b518 | -MIT | -
| github.com/buger/jsonparser | -github.com/buger/jsonparser-v1.0.0 | -MIT | -
| github.com/burntsushi/toml | -github.com/burntsushi/toml-v0.3.1 | -MIT | -
| github.com/caimeo/iniflags | -github.com/caimeo/iniflags-ef4ae6c5cd79d20db0b18bc5ebd8657fac7260e5 | -BSD 2 | -
| github.com/cloudflare/cfssl/log | -github.com/cloudflare/cfssl/log-v1.4.1 | -BSD 2 | -
| github.com/containernetworking/cni/libcni | -github.com/containernetworking/cni/libcni-v0.8.0 | -Apache 2.0 | -
| github.com/containernetworking/plugins/pkg/hns | -github.com/containernetworking/plugins/pkg/hns-v0.8.5 | -Apache 2.0 | -
| github.com/coreos/go-oidc | -github.com/coreos/go-oidc-v2.1.0 | -Apache 2.0 | -
| github.com/coreos/go-semver/semver | -github.com/coreos/go-semver/semver-v0.3.0 | -Apache 2.0 | -
| github.com/davecgh/go-spew/spew | -github.com/davecgh/go-spew/spew-v1.1.1 | -ISC | -
| github.com/docker/docker/api/types | -github.com/docker/docker/api/types-v1.13.1 | -Apache 2.0 | -
| github.com/docker/docker/client | -github.com/docker/docker/client-v1.13.1 | -Apache 2.0 | -
| github.com/docker/go-connections/nat | -github.com/docker/go-connections/nat-v0.4.0 | -Apache 2.0 | -
| github.com/docopt/docopt-go | -github.com/docopt/docopt-go-ee0de3bc6815ee19d4a46c7eb90f829db0e014b1 | -MIT | -
| github.com/elastic/go-elasticsearch/v7 | -github.com/elastic/go-elasticsearch/v7-v7.3.0 | -Apache 2.0 | -
| github.com/envoyproxy/data-plane-api/envoy/api/v2/core | -github.com/envoyproxy/data-plane-api/envoy/api/v2/core-ffd420ef8a9ad148642236aa6d89e2855b41c821 | -Apache 2.0 | -
| github.com/fsnotify/fsnotify | -github.com/fsnotify/fsnotify-v1.4.9 | -BSD 3 | -
| github.com/gavv/monotime | -github.com/gavv/monotime-30dba43534243e3484a34676a0f068d12b989f84 | -Apache 2.0 | -
| github.com/getlantern/deepcopy | -github.com/getlantern/deepcopy-v1 | -Apache 2.0 | -
| github.com/ghodss/yaml | -github.com/ghodss/yaml-v1.0.0 | -BSD 3 | -
| github.com/go-ini/ini | -github.com/go-ini/ini-v1.43.0 | -Apache 2.0 | -
| github.com/go-logr/logr | -github.com/go-logr/logr-v0.3.0 | -Apache 2.0 | -
| github.com/go-openapi/spec | -github.com/go-openapi/spec-v0.19.3 | -Apache 2.0 | -
| github.com/go-sql-driver/mysql | -github.com/go-sql-driver/mysql-v1.4.1 | -Mozilla 2.0 | -
| github.com/gofrs/flock | -github.com/gofrs/flock-v0.8.0 | -BSD 3 | -
| github.com/gogo/googleapis/google/rpc | -github.com/gogo/googleapis/google/rpc-v1.2.0 | -Apache 2.0 | -
| github.com/gogo/protobuf/proto | -github.com/gogo/protobuf/proto-v1.3.1 | -BSD 3 | -
| github.com/golang-collections/collections/stack | -github.com/golang-collections/collections/stack-604e922904d35e97f98a774db7881f049cd8d970 | -MIT | -
| github.com/google/go-cmp/cmp | -github.com/google/go-cmp/cmp-v0.4.0 | -BSD 3 | -
| github.com/google/gofuzz | -github.com/google/gofuzz-v1.1.0 | -Apache 2.0 | -
| github.com/google/gopacket | -github.com/google/gopacket-v1.1.18 | -BSD 3 | -
| github.com/google/netstack/tcpip/header | -github.com/google/netstack/tcpip/header-55fcc16cd0eb096d8418f7bc5162483c31a4e82b | -Apache 2.0 | -
| github.com/hashicorp/go-version | -github.com/hashicorp/go-version-v1.2.1 | -Mozilla 2.0 | -
| github.com/hashicorp/golang-lru | -github.com/hashicorp/golang-lru-v0.5.1 | -Mozilla 2.0 | -
| github.com/hashicorp/yamux | -github.com/hashicorp/yamux-2f1d1f20f75d5404f53b9edf6b53ed5505508675 | -Mozilla 2.0 | -
| github.com/howeyc/fsnotify | -github.com/howeyc/fsnotify-v0.9.0 | -BSD 3 | -
| github.com/hpcloud/tail | -github.com/hpcloud/tail-v1.0.0 | -MIT | -
| github.com/ishidawataru/sctp | -github.com/ishidawataru/sctp-00ab2ac2db07a138417639ef3f39672c65dbb9a0 | -BSD 3 | -
| github.com/jarcoal/httpmock | -github.com/jarcoal/httpmock-v1.0.5 | -MIT | -
| github.com/jinzhu/copier | -github.com/jinzhu/copier-v0.1.0 | -MIT | -
| github.com/jmespath/go-jmespath | -github.com/jmespath/go-jmespath-0.3.0 | -Apache 2.0 | -
| github.com/joho/godotenv | -github.com/joho/godotenv-v1.3.0 | -MIT | -
| github.com/jpillora/backoff | -github.com/jpillora/backoff-v1.0.0 | -MIT | -
| github.com/json-iterator/go | -github.com/json-iterator/go-v1.1.10 | -MIT | -
| github.com/juju/clock | -github.com/juju/clock-9c5c9712527c7986f012361e7d13756b4d99543d | -LGPL 3.0 | -
| github.com/juju/errors | -github.com/juju/errors-3fe23663418fc1d724868c84f21b7519bbac7441 | -LGPL 3.0 | -
| github.com/juju/mutex | -github.com/juju/mutex-d21b13acf4bfd8a8b0482a3a78e44d98880b40d3 | -LGPL 3.0 | -
| github.com/k8snetworkplumbingwg/network-attachment-definition-client/pkg/utils | -github.com/k8snetworkplumbingwg/network-attachment-definition-client/pkg/utils-v1.1.0 | -Apache 2.0 | -
| github.com/kardianos/osext | -github.com/kardianos/osext-2bc1f35cddc0cc527b4bc3dce8578fc2a6c11384 | -BSD 3 | -
| github.com/kelseyhightower/envconfig | -github.com/kelseyhightower/envconfig-v1.4.0 | -MIT | -
| github.com/kelseyhightower/memkv | -github.com/kelseyhightower/memkv-v0.1.1 | -MIT | -
| github.com/konsorten/go-windows-terminal-sequences | -github.com/konsorten/go-windows-terminal-sequences-v1.0.1 | -MIT | -
| github.com/lestrrat-go/file-rotatelogs | -github.com/lestrrat-go/file-rotatelogs-v2.4.0 | -MIT | -
| github.com/libp2p/go-reuseport | -github.com/libp2p/go-reuseport-v0.0.1 | -ISC | -
| github.com/lithammer/dedent | -github.com/lithammer/dedent-v1.1.0 | -MIT | -
| github.com/mailru/easyjson | -github.com/mailru/easyjson-v0.7.0 | -MIT | -
| github.com/masterminds/sprig | -github.com/masterminds/sprig-v2.19.0 | -MIT | -
| github.com/mcuadros/go-version | -github.com/mcuadros/go-version-92cdf37c5b7579ebaf7a036da94b40995972088d | -MIT | -
| github.com/microsoft/hcsshim | -github.com/microsoft/hcsshim-v0.8.6 | -MIT | -
| github.com/mipearson/rfw | -github.com/mipearson/rfw-6f0a6f3266ba1058df9ef0c94cda1cecd2e62852 | -MIT | -
| github.com/mitchellh/go-homedir | -github.com/mitchellh/go-homedir-v1.1.0 | -MIT | -
| github.com/modern-go/concurrent | -github.com/modern-go/concurrent-1.0.3 | -Apache 2.0 | -
| github.com/modern-go/reflect2 | -github.com/modern-go/reflect2-v1.0.1 | -Apache 2.0 | -
| github.com/natefinch/atomic | -github.com/natefinch/atomic-a62ce929ffcc871a51e98c6eba7b20321e3ed62d | -MIT | -
| github.com/nmrshll/go-cp | -github.com/nmrshll/go-cp-61436d3b7cfa1bc1e8e455c35d8f60b8e51ccc2e | -MIT | -
| github.com/nxadm/tail | -github.com/nxadm/tail-v1.4.4 | -MIT | -
| github.com/olekukonko/tablewriter | -github.com/olekukonko/tablewriter-v0.0.2 | -MIT | -
| github.com/olivere/elastic/v7 | -github.com/olivere/elastic/v7-v7.0.6 | -MIT | -
| github.com/onsi/ginkgo | -github.com/onsi/ginkgo-v1.15.0 | -MIT | -
| github.com/onsi/gomega | -github.com/onsi/gomega-v1.7.0 | -MIT | -
| github.com/openshift/api/config/v1 | -github.com/openshift/api/config/v1-d0822898eabb929c40c5146116252477abab8d18 | -Apache 2.0 | -
| github.com/openshift/library-go/pkg/crypto | -github.com/openshift/library-go/pkg/crypto-9350cd67a9110bcaf9a85d391fa264afbbff1342 | -Apache 2.0 | -
| github.com/osrg/gobgp/client | -github.com/osrg/gobgp/client-v1.22 | -Apache 2.0 | -
| github.com/paloaltonetworks/pango | -github.com/paloaltonetworks/pango-v0.1.1 | -ISC | -
| github.com/patrickmn/go-cache | -github.com/patrickmn/go-cache-v2.1.0 | -MIT | -
| github.com/pkg/errors | -github.com/pkg/errors-v0.8.1 | -BSD 2 | -
| github.com/projectcalico/cni-plugin | -github.com/projectcalico/cni-plugin | -Apache 2.0 | -
| github.com/projectcalico/felix | -github.com/projectcalico/felix | -Apache 2.0 | -
| github.com/projectcalico/go-json | -github.com/projectcalico/go-json/json-6219dc7339ba20ee4c57df0a8baac62317d19cb1 | -BSD 2 | -
| github.com/projectcalico/go-yaml-wrapper | -github.com/projectcalico/go-yaml-wrapper-090425220c545f6d179db17af395f5aac30b6926 | -BSD 3 | -
| kube-controllers | -kube-controllers | -Tigera Proprietary | -
| github.com/projectcalico/libcalico-go | -github.com/projectcalico/libcalico-go/lib | -Apache 2.0 | -
| github.com/projectcalico/pod2daemon | -github.com/projectcalico/pod2daemon | -Apache 2.0 | -
| typha | -typha | -Tigera Proprietary | -
| github.com/prometheus/client_golang/ | -github.com/prometheus/client_golang/prometheus-v1.7.1 | -Apache 2.0 | -
| github.com/rakelkar/gonetsh/netsh | -github.com/rakelkar/gonetsh/netsh-e5c5ffe4bdf04bc060fc45ff4aca2349f51c94a7 | -Apache 2.0 | -
| github.com/robfig/cron | -github.com/robfig/cron-v1.2.0 | -MIT | -
| github.com/satori/go.uuid | -github.com/satori/go.uuid-v1.2.0 | -MIT | -
| github.com/shirou/gopsutil/process | -github.com/shirou/gopsutil/process-v2.19.03 | -BSD 3 | -
| github.com/sirupsen/logrus | -github.com/sirupsen/logrus-v1.4.2 | -MIT | -
| github.com/sirupsen/logrus | -github.com/sirupsen/logrus-v1.6.0 | -MIT | -
| github.com/spf13/cobra | -github.com/spf13/cobra-v0.0.3 | -Apache 2.0 | -
| github.com/spf13/cobra | -github.com/spf13/cobra-v1.0.0 | -Apache 2.0 | -
| github.com/spf13/pflag | -github.com/spf13/pflag-v1.0.5 | -BSD 3 | -
| github.com/spf13/viper | -github.com/spf13/viper-v1.6.1 | -MIT | -
| github.com/stretchr/testify | -github.com/stretchr/testify/mock-v1.4.0 | -MIT | -
| github.com/termie/go-shutil | -github.com/termie/go-shutil-bcacb06fecaeec8dc42af03c87c6949f4a05c74c | -MIT | -
| github.com/tigera/api | -github.com/tigera/api/ | -Apache 2.0 | -
| github.com/vishvananda/netlink | -github.com/vishvananda/netlink-v1.1.0 | -Apache 2.0 | -
| github.com/willf/bitset | -github.com/willf/bitset-v1.1.11 | -BSD 3 | -
| github.com/workiva/go-datastructures/trie/ctrie | -github.com/workiva/go-datastructures/trie/ctrie-v1.0.50 | -Apache 2.0 | -
| github.com/x-cray/logrus-prefixed-formatter | -github.com/x-cray/logrus-prefixed-formatter-v0.5.2 | -MIT | -
| github.com/yalp/jsonpath | -github.com/yalp/jsonpath-5cc68e5049a040829faef3a44c00ec4332f6dec7 | -BSD 3 | -
| global | -global-4.4.0.tgz | -MIT | -
| go.etcd.io/etcd/ | -go.etcd.io/etcd/client-v0.5.0-alpha.5.0.20201125193152-8a03d2e9614b | -Apache 2.0 | -
| go.uber.org/zap | -go.uber.org/zap-v1.15.0 | -MIT | -
| golang.org/x/crypto | -golang.org/x/crypto/ | -BSD 3 | -
| golang.org/x/net | -golang.org/x/net/ | -BSD 3 | -
| golang.org/x/sync/ | -golang.org/x/sync/ | -BSD 3 | -
| golang.org/x/sys | -golang.org/x/sys | -BSD 3 | -
| github.com/golang/text | -golang.org/x/text | -Golang BSD + Patents | -
| golang.zx2c4.com/wireguard/ | -golang.zx2c4.com/wireguard/ | -MIT | -
| google-libphonenumber | -google-libphonenumber-3.2.2.tgz | -Apache 2.0 | -
| google.golang.org/grpc | -google.golang.org/grpc-v1.27.0 | -Apache 2.0 | -
| google-auth | -google_auth-1.26.1-py2.py3-none-any.whl | -Apache 2.0 | -
| gopkg.in/fsnotify/fsnotify.v1 | -gopkg.in/fsnotify/fsnotify.v1-v1.4.7 | -BSD 3 | -
| gopkg.in/go-playground/validator.v9 | -gopkg.in/go-playground/validator.v9-v9.30.2 | -MIT | -
| gopkg.in/inf.v0 | -gopkg.in/inf.v0-v0.9.0 | -BSD 3 | -
| gopkg.in/natefinch/lumberjack.v2 | -gopkg.in/natefinch/lumberjack.v2-v2.0.0 | -MIT | -
| gopkg.in/square/go-jose.v2 | -gopkg.in/square/go-jose.v2-v2.2.3 | -Apache 2.0 | -
| gopkg.in/tchap/go-patricia.v2/patricia | -gopkg.in/tchap/go-patricia.v2/patricia-v2.3.0 | -MIT | -
| gopkg.in/tomb.v1 | -gopkg.in/tomb.v1-dd632973f1e7218eb1089048e0798ec9ae7dceb8 | -BSD 3 | -
| gopkg.in/yaml.v2 | -gopkg.in/yaml.v2-v2.4.0 | -Apache 2.0 | -
| graphlib | -graphlib-2.1.8.tgz | -MIT | -
| gud | -gud-1.0.0.tgz | -MIT | -
| has | -has-1.0.3.tgz | -MIT | -
| has-flag | -has-flag-3.0.0.tgz | -MIT | -
| has-symbols | -has-symbols-1.0.1.tgz | -MIT | -
| has-value | -has-value-0.3.1.tgz | -MIT | -
| has-value | -has-value-1.0.0.tgz | -MIT | -
| has-values | -has-values-0.1.4.tgz | -MIT | -
| has-values | -has-values-1.0.0.tgz | -MIT | -
| he | -he-1.2.0.tgz | -MIT | -
| heap | -heap-0.2.6.tgz | -Python 2.0 | -
| @babel/helper-validator-identifier | -helper-validator-identifier-7.10.1.tgz | -MIT | -
| @babel/highlight | -highlight-7.10.1.tgz | -MIT | -
| history | -history-4.9.0.tgz | -MIT | -
| hogan.js | -Apache 2.0 | -|
| hogan.js | -hogan.js-3.0.2.tgz | -Apache 2.0 | -
| hoist-non-react-statics | -hoist-non-react-statics-3.1.0.tgz | -BSD 3 | -
| hoist-non-react-statics | -hoist-non-react-statics-3.3.0.tgz | -BSD 3 | -
| @types/html-minifier-terser | -html-minifier-terser-5.1.0.tgz | -MIT | -
| html-minifier-terser | -html-minifier-terser-5.1.1.tgz | -MIT | -
| html-webpack-plugin | -html-webpack-plugin-4.3.0.tgz | -MIT | -
| htmlparser2 | -htmlparser2-3.10.1.tgz | -MIT | -
| humps | -humps-2.0.1.tgz | -MIT | -
| icepick | -icepick-1.3.0.tgz | -MIT | -
| iconv-lite | -iconv-lite-0.4.23.tgz | -MIT | -
| idna | -idna-2.10-py2.py3-none-any.whl | -BSD 3 | -
| idna | -idna-2.7-py2.py3-none-any.whl | -BSD 2 | -
| immutable | -immutable-3.8.2.tgz | -MIT | -
| importlib-metadata | -importlib_metadata-2.1.1-py2.py3-none-any.whl | -Apache 2.0 | -
| inherits | -inherits-2.0.4.tgz | -ISC | -
| instantsearch.js | -instantsearch.production-4.4.1.min.js | -MIT | -
| invariant | -invariant-2.2.2.tgz | -BSD 3 | -
| invariant | -invariant-2.2.4.tgz | -MIT | -
| ip-regex | -ip-regex-2.1.0.tgz | -MIT | -
| ip-regex | -ip-regex-4.1.0.tgz | -MIT | -
| ipaddr.js | -ipaddr.js-1.9.1.tgz | -MIT | -
| ipaddress | -ipaddress-1.0.23-py2.py3-none-any.whl | -Python 2.0 | -
| is-accessor-descriptor | -is-accessor-descriptor-0.1.6.tgz | -MIT | -
| is-accessor-descriptor | -is-accessor-descriptor-1.0.0.tgz | -MIT | -
| is-buffer | -is-buffer-1.1.6.tgz | -MIT | -
| is-callable | -is-callable-1.1.5.tgz | -MIT | -
| is-cidr | -is-cidr-3.1.0.tgz | -BSD 2 | -
| is-data-descriptor | -is-data-descriptor-0.1.4.tgz | -MIT | -
| is-data-descriptor | -is-data-descriptor-1.0.0.tgz | -MIT | -
| is-date-object | -is-date-object-1.0.1.tgz | -MIT | -
| is-descriptor | -is-descriptor-0.1.6.tgz | -MIT | -
| is-descriptor | -is-descriptor-1.0.2.tgz | -MIT | -
| is-extendable | -is-extendable-0.1.1.tgz | -MIT | -
| is-extendable | -is-extendable-1.0.1.tgz | -MIT | -
| is-ip | -is-ip-3.1.0.tgz | -MIT | -
| is-number | -is-number-3.0.0.tgz | -MIT | -
| is-plain-object | -is-plain-object-2.0.4.tgz | -MIT | -
| is-regex | -is-regex-1.0.5.tgz | -MIT | -
| is-stream | -is-stream-1.1.0.tgz | -MIT | -
| is-symbol | -is-symbol-1.0.3.tgz | -MIT | -
| is-windows | -is-windows-1.0.2.tgz | -MIT | -
| isarray | -isarray-0.0.1.tgz | -MIT | -
| isarray | -isarray-1.0.0.tgz | -MIT | -
| isobject | -isobject-2.1.0.tgz | -MIT | -
| isobject | -isobject-3.0.1.tgz | -MIT | -
| isomorphic-fetch | -isomorphic-fetch-2.2.1.tgz | -MIT | -
| jquery | -jquery-2.2.0.min.js | -MIT | -
| jquery | -jquery-3.4.0.min.js | -MIT | -
| js-cookie | -js-cookie-2.2.1.tgz | -MIT | -
| js-tokens | -js-tokens-3.0.2.tgz | -MIT | -
| js-tokens | -js-tokens-4.0.0.tgz | -MIT | -
| js-yaml | -js-yaml-3.14.0.tgz | -MIT | -
| jsan | -jsan-3.1.13.tgz | -MIT | -
| json5 | -json5-1.0.1.tgz | -MIT | -
| jsonpickle | -jsonpickle-2.0.0-py2.py3-none-any.whl | -BSD 2 | -
| jsrsasign | -jsrsasign-5.1.0.tgz | -MIT | -
| k8s.io/api | -k8s.io/api | -Apache 2.0 | -
| k8s.io/apiextensions-apiserver/ | -k8s.io/apiextensions-apiserver/ | -Apache 2.0 | -
| k8s.io/apimachinery | -k8s.io/apimachinery/ | -Apache 2.0 | -
| k8s.io/apiserver | -k8s.io/apiserver | -Apache 2.0 | -
| k8s.io/client-go | -k8s.io/client-go/ | -Apache 2.0 | -
| k8s.io/component-base/ | -k8s.io/component-base/ | -Apache 2.0 | -
| k8s.io/klog | -k8s.io/klog-v1.0.0 | -Apache 2.0 | -
| k8s.io/kube-aggregator/ | -k8s.io/kube-aggregator/ | -Apache 2.0 | -
| k8s.io/kube-openapi/ | -k8s.io/kube-openapi | -Apache 2.0 | -
| k8s.io/kubernetes/ | -k8s.io/kubernetes/ | -Apache 2.0 | -
| k8s.io/utils/strings | -k8s.io/utils/strings | -Apache 2.0 | -
| keycode | -keycode-2.1.9.tgz | -MIT | -
| kind-of | -kind-of-3.2.2.tgz | -MIT | -
| kind-of | -kind-of-4.0.0.tgz | -MIT | -
| kind-of | -kind-of-5.1.0.tgz | -MIT | -
| kind-of | -kind-of-6.0.3.tgz | -MIT | -
| kube-controllers | -kube-controllers-v3.0.11 | -Tigera Proprietary | -
| kube-controllers | -kube-controllers-v3.16.6 | -Tigera Proprietary | -
| kubernetes | -kubernetes-12.0.1-py2.py3-none-any.whl | -Apache 2.0 | -
| layout-base | -layout-base-1.0.2.tgz | -MIT | -
| projectcalico | -libcalico-go-v3.18.0-0.dev | -Apache 2.0 | -
| loader-utils | -loader-utils-1.4.0.tgz | -MIT | -
| lodash | -lodash-4.17.19.tgz | -MIT | -
| lodash | -lodash-4.17.20.tgz | -MIT | -
| lodash-es | -lodash-es-4.17.15.tgz | -MIT | -
| lodash.debounce | -lodash.debounce-4.0.8.tgz | -MIT | -
| lodash.get | -lodash.get-4.4.2.tgz | -MIT | -
| lodash.isequal | -lodash.isequal-4.5.0.tgz | -MIT | -
| lodash.throttle | -lodash.throttle-4.1.1.tgz | -MIT | -
| lodash.topath | -lodash.topath-4.5.2.tgz | -MIT | -
| pimterry | -loglevel-v1.6.8 | -MIT | -
| loose-envify | -loose-envify-1.3.1.tgz | -MIT | -
| loose-envify | -loose-envify-1.4.0.tgz | -MIT | -
| lower-case | -lower-case-2.0.1.tgz | -MIT | -
| map-cache | -map-cache-0.2.2.tgz | -MIT | -
| map-visit | -map-visit-1.0.0.tgz | -MIT | -
| math-expression-evaluator | -math-expression-evaluator-1.2.17.tgz | -MIT | -
| megacubo | -megacubo-br-Megacubo_15.4.7_linux_ia32 | -LGPL 2.1 | -
| memoize-one | -memoize-one-4.0.3.tgz | -MIT | -
| microevent.ts | -microevent.ts-0.1.1.tgz | -MIT | -
| micromatch | -micromatch-3.1.10.tgz | -MIT | -
| min-document | -min-document-2.19.0.tgz | -MIT | -
| mini-create-react-context | -mini-create-react-context-0.3.2.tgz | -MIT | -
| minimatch | -minimatch-3.0.4.tgz | -ISC | -
| minimist | -minimist-1.2.5.tgz | -MIT | -
| mixin-deep | -mixin-deep-1.3.2.tgz | -MIT | -
| mkdirp | -mkdirp-0.3.0.tgz | -MIT X11 | -
| mocha | -mocha-1.6.0.js | -MIT | -
| moment | -moment-2.22.2.tgz | -MIT | -
| more-itertools | -more_itertools-5.0.0-py2-none-any.whl | -MIT | -
| ms | -ms-2.0.0.tgz | -MIT | -
| nanoid | -nanoid-2.1.7.tgz | -MIT | -
| nanomatch | -nanomatch-1.2.13.tgz | -MIT | -
| netaddr | -netaddr-0.7.19-py2.py3-none-any.whl | -BSD 3 | -
| no-case | -no-case-3.0.3.tgz | -MIT | -
| @types/node | -node-9.3.0.tgz | -MIT | -
| node-fetch | -node-fetch-1.7.3.tgz | -MIT | -
| nodejs | -node-v10.23.1 | -Node.js | -
| node | -node-v3.17.2 | -Tigera Proprietary | -
| nopt | -nopt-1.0.10.tgz | -MIT | -
| nose-timer | -nose-timer-0.7.1.tar.gz | -MIT | -
| nose-parameterized | -nose_parameterized-0.6.0-py2.py3-none-any.whl | -BSD 3 | -
| nth-check | -nth-check-1.0.2.tgz | -BSD 2 | -
| oauthlib | -oauthlib-3.1.0-py2.py3-none-any.whl | -BSD 3 | -
| object-assign | -object-assign-4.1.1.tgz | -MIT | -
| object-copy | -object-copy-0.1.0.tgz | -MIT | -
| object-inspect | -object-inspect-1.7.0.tgz | -MIT | -
| object-keys | -object-keys-1.0.11.tgz | -MIT | -
| object-keys | -object-keys-1.1.1.tgz | -MIT | -
| object-visit | -object-visit-1.0.1.tgz | -MIT | -
| object.assign | -object.assign-4.1.0.tgz | -MIT | -
| object.getownpropertydescriptors | -object.getownpropertydescriptors-2.1.0.tgz | -MIT | -
| object.pick | -object.pick-1.3.0.tgz | -MIT | -
| oidc-client | -oidc-client-1.4.1.tgz | -Apache 2.0 | -
| openshift | -origin-v3.6.1 | -Apache 2.0 | -
| packaging | -packaging-20.9-py2.py3-none-any.whl | -BSD 2 | -
| param-case | -param-case-3.0.3.tgz | -MIT | -
| parse-duration | -parse-duration-0.4.4.tgz | -MIT | -
| pascal-case | -pascal-case-3.1.1.tgz | -MIT | -
| pascalcase | -pascalcase-0.1.1.tgz | -MIT | -
| path-to-regexp | -path-to-regexp-1.7.0.tgz | -MIT | -
| pathlib2 | -pathlib2-2.3.5-py2.py3-none-any.whl | -MIT | -
| pegjs | -pegjs-0.10.0.tgz | -MIT | -
| performance-now | -performance-now-2.1.0.tgz | -MIT | -
| pluggy | -pluggy-0.13.1-py2.py3-none-any.whl | -MIT | -
| popper.js | -popper-1.16.0.js | -MIT | -
| popper.js | -popper.js-1.16.1.tgz | -MIT | -
| posix-character-classes | -posix-character-classes-0.1.1.tgz | -MIT | -
| pretty-error | -pretty-error-2.1.1.tgz | -MIT | -
| process | -process-0.11.10.tgz | -MIT | -
| promise | -promise-7.3.1.tgz | -MIT | -
| prop-types | -prop-types-15.5.10.js | -BSD 3 | -
| prop-types | -prop-types-15.6.0.tgz | -MIT | -
| prop-types | -prop-types-15.6.2.js | -BSD 3 | -
| prop-types | -prop-types-15.6.2.tgz | -MIT | -
| prop-types | -prop-types-15.7.2.tgz | -MIT | -
| prop-types-extra | -prop-types-extra-1.0.1.tgz | -MIT | -
| py | -py-1.10.0-py2.py3-none-any.whl | -MIT | -
| pyasn1 | -pyasn1-0.4.8-py2.py3-none-any.whl | -BSD 2 | -
| pyasn1-modules | -pyasn1_modules-0.2.8-py2.py3-none-any.whl | -BSD 2 | -
| pyparsing | -pyparsing-2.4.7-py2.py3-none-any.whl | -MIT | -
| pytest | -pytest-4.6.11-py2.py3-none-any.whl | -MIT | -
| python-dateutil | -python_dateutil-2.8.1-py2.py3-none-any.whl | -BSD 3 | -
| PyYAML | -PyYAML-5.4.1-cp27-cp27mu-manylinux1_x86_64.whl | -MIT | -
| raf | -raf-3.4.0.tgz | -MIT | -
| raf-schd | -raf-schd-4.0.0.tgz | -MIT | -
| raven-js | -raven-js-3.22.1.tgz | -BSD 2 | -
| react | -react-15.6.1.js | -MIT | -
| react | -react-16.13.1.tgz | -MIT | -
| react | -react-16.8.6.tgz | -MIT | -
| react-beautiful-dnd | -react-beautiful-dnd-10.0.2.tgz | -Apache 2.0 | -
| react-bootstrap | -react-bootstrap-0.32.1.tgz | -MIT | -
| react-codemirror2 | -react-codemirror2-5.1.0.tgz | -MIT | -
| react-confirm | -react-confirm-0.1.16.tgz | -MIT | -
| react-cytoscapejs | -react-cytoscapejs-1.2.1.tgz | -MIT | -
| plotly | -react-cytoscapejs-v1.2.1 | -MIT | -
| react-day-picker | -react-day-picker-7.4.8.tgz | -MIT | -
| react-dom | -react-dom-15.6.1.js | -MIT | -
| react-dom | -react-dom-16.13.1.tgz | -MIT | -
| react-dom | -react-dom-16.8.6.tgz | -MIT | -
| react-draggable | -react-draggable-3.0.5.tgz | -MIT | -
| react-fast-compare | -react-fast-compare-2.0.4.tgz | -MIT | -
| react-filter-box | -react-filter-box-3.4.1.tgz | -MIT | -
| @fortawesome/react-fontawesome | -react-fontawesome-0.1.3.tgz | -MIT | -
| react-grid-layout | -react-grid-layout-0.16.3.tgz | -MIT | -
| react-hot-loader | -react-hot-loader-4.12.21.tgz | -MIT | -
| react-input-autosize | -react-input-autosize-2.1.2.tgz | -MIT | -
| JedWatson | -react-input-autosize-v2.1.2 | -MIT | -
| react-is | -react-is-16.6.3.tgz | -MIT | -
| react-is | -react-is-16.8.6.tgz | -MIT | -
| react-is | -react-is-16.9.0.tgz | -MIT | -
| react-json-pretty | -react-json-pretty-2.2.0.tgz | -MIT | -
| react-lifecycles-compat | -react-lifecycles-compat-3.0.4.tgz | -MIT | -
| react-native-segmented-control-tab | -react-native-segmented-control-tab-3.2.1.tgz | -MIT | -
| react-new-window | -react-new-window-0.1.2.tgz | -MIT | -
| react-notification-system | -react-notification-system-0.2.17.tgz | -MIT | -
| react-overlays | -react-overlays-0.8.3.tgz | -MIT | -
| react-prop-types | -react-prop-types-0.4.0.tgz | -MIT | -
| react-querybuilder | -react-querybuilder-3.0.0.tgz | -MIT | -
| react-redux | -react-redux-5.1.1.tgz | -MIT | -
| react-redux | -react-redux-7.1.1.tgz | -MIT | -
| react-redux-form | -react-redux-form-1.16.5.tgz | -MIT | -
| react-resizable | -react-resizable-1.7.5.tgz | -MIT | -
| react-resize-detector | -react-resize-detector-2.3.0.tgz | -MIT | -
| react-router | -react-router-5.0.1.tgz | -MIT | -
| react-router-dom | -react-router-dom-5.0.1.tgz | -MIT | -
| react-show | -react-show-2.0.4.tgz | -MIT | -
| react-smooth | -react-smooth-1.0.2.tgz | -MIT | -
| react-split-pane | -react-split-pane-0.1.92.tgz | -MIT | -
| react-style-proptype | -react-style-proptype-3.2.2.tgz | -MIT | -
| react-switch | -react-switch-5.0.0.tgz | -MIT | -
| react-table-6 | -react-table-6-6.11.0.tgz | -MIT | -
| react-table | -react-table-7.5.1.tgz | -MIT | -
| react-tooltip | -react-tooltip-4.2.11.tgz | -MIT | -
| react-transition-group | -react-transition-group-2.2.1.tgz | -BSD 3 | -
| react-transition-group | -react-transition-group-2.7.1.tgz | -BSD 3 | -
| readable-stream | -readable-stream-3.6.0.tgz | -MIT | -
| recharts | -recharts-1.5.0.tgz | -MIT | -
| recharts-scale | -recharts-scale-0.4.2.tgz | -MIT | -
| reduce-css-calc | -reduce-css-calc-1.3.0.tgz | -MIT | -
| reduce-function-call | -reduce-function-call-1.0.2.tgz | -MIT | -
| redux | -redux-4.0.1.tgz | -MIT | -
| redux | -redux-4.0.4.tgz | -MIT | -
| redux-immutable | -redux-immutable-4.0.0.tgz | -BSD 3 | -
| redux-merge-immutable-reducers | -redux-merge-immutable-reducers-0.1.4.tgz | -MIT | -
| redux-thunk | -redux-thunk-2.3.0.tgz | -MIT | -
| reflect-metadata | -reflect-metadata-0.1.13.tgz | -Apache 2.0 | -
| regenerator-runtime | -regenerator-runtime-0.11.1.tgz | -MIT | -
| regenerator-runtime | -regenerator-runtime-0.12.1.tgz | -MIT | -
| regenerator-runtime | -regenerator-runtime-0.13.3.tgz | -MIT | -
| regenerator-runtime | -regenerator-runtime-0.13.5.tgz | -MIT | -
| regex-not | -regex-not-1.0.2.tgz | -MIT | -
| regexp-to-ast | -regexp-to-ast-0.4.0.tgz | -MIT | -
| relateurl | -relateurl-0.2.7.tgz | -MIT | -
| remotedev-serialize | -remotedev-serialize-0.1.8.tgz | -MIT | -
| renderkid | -renderkid-2.0.3.tgz | -MIT | -
| repeat-element | -repeat-element-1.1.3.tgz | -MIT | -
| repeat-string | -repeat-string-1.6.1.tgz | -MIT | -
| requests | -requests-2.20.1-py2.py3-none-any.whl | -Apache 2.0 | -
| requests | -requests-2.25.1-py2.py3-none-any.whl | -Apache 2.0 | -
| requests-oauthlib | -requests_oauthlib-1.3.0-py2.py3-none-any.whl | -ISC | -
| reselect | -reselect-2.5.4.tgz | -MIT | -
| @juggle/resize-observer | -resize-observer-3.2.0.tgz | -Apache 2.0 | -
| resize-observer-polyfill | -resize-observer-polyfill-1.5.1.tgz | -MIT | -
| resolve-pathname | -resolve-pathname-2.2.0.tgz | -MIT | -
| resolve-url | -resolve-url-0.2.1.tgz | -MIT | -
| ret | -ret-0.1.15.tgz | -MIT | -
| rsa | -rsa-4.5-py2.py3-none-any.whl | -Apache 2.0 | -
| @babel/runtime | -runtime-7.1.5.tgz | -MIT | -
| @babel/runtime | -runtime-7.5.5.tgz | -MIT | -
| @babel/runtime-corejs2 | -runtime-corejs2-7.1.5.tgz | -MIT | -
| rw | -rw-1.3.3.tgz | -BSD 3 | -
| safe-buffer | -safe-buffer-5.2.1.tgz | -MIT | -
| safe-regex | -safe-regex-1.1.0.tgz | -MIT | -
| safer-buffer | -safer-buffer-2.1.2.tgz | -MIT | -
| scandir | -scandir-1.10.0.tar.gz | -BSD 3 | -
| scheduler | -scheduler-0.13.6.tgz | -MIT | -
| scheduler | -scheduler-0.18.0.tgz | -MIT | -
| scheduler | -scheduler-0.19.1.tgz | -MIT | -
| seamless-immutable | -seamless-immutable-7.1.4.tgz | -BSD 3 | -
| semver | -semver-5.7.1.tgz | -ISC | -
| set-value | -set-value-2.0.1.tgz | -MIT | -
| setimmediate | -setimmediate-1.0.5.tgz | -MIT | -
| setuptools | -setuptools-44.1.1-py2.py3-none-any.whl | -MIT | -
| shallow-compare | -shallow-compare-1.2.2.tgz | -MIT | -
| shallowequal | -shallowequal-1.1.0.tgz | -MIT | -
| sigs.k8s.io/controller-runtime | -sigs.k8s.io/controller-runtime-v0.7.0 | -Apache 2.0 | -
| sigs.k8s.io/kind/pkg/errors | -sigs.k8s.io/kind/pkg/errors-v0.9.0 | -Apache 2.0 | -
| sigs.k8s.io/yaml | -sigs.k8s.io/yaml-v1.2.0 | -BSD 3 | -
| simplejson | -simplejson-3.13.2.tar.gz | -Academic 2.1 | -
| six | -six-1.15.0-py2.py3-none-any.whl | -MIT | -
| snapdragon | -snapdragon-0.8.2.tgz | -MIT | -
| snapdragon-node | -snapdragon-node-2.1.1.tgz | -MIT | -
| snapdragon-util | -snapdragon-util-3.0.1.tgz | -MIT | -
| soupsieve | -soupsieve-1.9.6-py2.py3-none-any.whl | -MIT | -
| @types/source-list-map | -source-list-map-0.1.2.tgz | -MIT | -
| source-map | -source-map-0.5.7.tgz | -BSD 3 | -
| source-map | -source-map-0.6.1.tgz | -BSD 3 | -
| source-map | -source-map-0.7.3.tgz | -BSD 3 | -
| source-map-resolve | -source-map-resolve-0.5.3.tgz | -MIT | -
| source-map-support | -source-map-support-0.5.19.tgz | -MIT | -
| source-map-url | -source-map-url-0.4.0.tgz | -MIT | -
| split-string | -split-string-3.1.0.tgz | -MIT | -
| sprintf | -sprintf-1.0.3.js | -BSD | -
| sprintf-js | -sprintf-js-1.0.3.tgz | -BSD 3 | -
| static-extend | -static-extend-0.1.2.tgz | -MIT | -
| string.prototype.trimend | -string.prototype.trimend-1.0.1.tgz | -MIT | -
| string.prototype.trimleft | -string.prototype.trimleft-2.1.2.tgz | -MIT | -
| string.prototype.trimright | -string.prototype.trimright-2.1.2.tgz | -MIT | -
| string.prototype.trimstart | -string.prototype.trimstart-1.0.1.tgz | -MIT | -
| string_decoder | -string_decoder-1.3.0.tgz | -MIT | -
| strip-ansi | -strip-ansi-3.0.1.tgz | -MIT | -
| strongly-connected-components | -strongly-connected-components-1.0.1.tgz | -MIT | -
| supports-color | -supports-color-5.5.0.tgz | -MIT | -
| swagger-ui | -swagger-ui-bundle-3.37.0.js | -Apache 2.0 | -
| swagger-ui | -swagger-ui-standalone-preset-3.37.0.js | -Apache 2.0 | -
| symbol-observable | -symbol-observable-1.2.0.tgz | -MIT | -
| @types/tapable | -tapable-1.0.5.tgz | -MIT | -
| tapable | -tapable-1.1.3.tgz | -MIT | -
| Jstarfish | -Technical-Learning-609d9d75ca68e30aee8757b26f52bf132c644be7 | -ISC | -
| termcolor | -termcolor-1.1.0.tar.gz | -MIT | -
| terser | -terser-4.7.0.tgz | -BSD 2 | -
| tiny-invariant | -tiny-invariant-1.0.3.tgz | -MIT | -
| tiny-invariant | -tiny-invariant-1.0.6.tgz | -MIT | -
| tiny-warning | -tiny-warning-1.0.2.tgz | -MIT | -
| tiny-warning | -tiny-warning-1.0.3.tgz | -MIT | -
| tippy.js | -tippy-bundle.iife-5.2.1.min.js | -MIT | -
| tippy.js | -tippy.js-6.2.5.tgz | -MIT | -
| to-object-path | -to-object-path-0.3.0.tgz | -MIT | -
| to-regex | -to-regex-3.0.2.tgz | -MIT | -
| to-regex-range | -to-regex-range-2.1.1.tgz | -MIT | -
| tslib | -tslib-1.10.0.js | -Apache 2.0 | -
| tslib | -tslib-1.10.0.tgz | -Apache 2.0 | -
| tslib | -tslib-1.13.0.js | -Apache 2.0 | -
| tslib | -tslib.es6-1.10.0.js | -Apache 2.0 | -
| tslib | -tslib.es6-1.13.0.js | -Apache 2.0 | -
| typescript-fsa | -typescript-fsa-2.5.0.tgz | -MIT | -
| typescript-fsa-reducers | -typescript-fsa-reducers-0.4.5.tgz | -MIT | -
| ua-parser-js | -ua-parser-js-0.7.18.tgz | -MIT | -
| @types/uglify-js | -uglify-js-3.9.2.tgz | -MIT | -
| uncontrollable | -uncontrollable-4.1.0.tgz | -MIT | -
| union-value | -union-value-1.0.1.tgz | -MIT | -
| unset-value | -unset-value-1.0.0.tgz | -MIT | -
| urix | -urix-0.1.0.tgz | -MIT | -
| urllib3 | -urllib3-1.24.3-py2.py3-none-any.whl | -MIT | -
| urllib3 | -urllib3-1.26.3-py2.py3-none-any.whl | -MIT | -
| use | -use-3.1.1.tgz | -MIT | -
| util-deprecate | -util-deprecate-1.0.2.tgz | -MIT | -
| util.promisify | -util.promisify-1.0.0.tgz | -MIT | -
| utila | -utila-0.4.0.tgz | -MIT | -
| uuid | -uuid-7.0.3.tgz | -MIT | -
| validator | -validator-10.4.0.tgz | -MIT | -
| value-equal | -value-equal-0.4.0.tgz | -MIT | -
| warning | -warning-3.0.0.tgz | -BSD 3 | -
| wcwidth | -wcwidth-0.2.5-py2.py3-none-any.whl | -MIT | -
| @types/webpack | -webpack-4.41.17.tgz | -MIT | -
| @types/webpack-sources | -webpack-sources-1.4.0.tgz | -MIT | -
| websocket_client | -websocket_client-0.57.0-py2.py3-none-any.whl | -BSD 3 | -
| whatwg-fetch | -whatwg-fetch-2.0.4.tgz | -MIT | -
| worker-rpc | -worker-rpc-0.1.1.tgz | -MIT | -
| zipp | -zipp-1.2.0-py2.py3-none-any.whl | -MIT | -
| github.com/projectcalico/bird | -github.com/projectcalico/bird/blob/v0.3.3 | -GPL | -
| egress-gateway | -egress-gateway | -Tigera Proprietary | -
FELIX_BPFENABLED | Enable eBPF dataplane mode. eBPF mode has a number of limitations, see the [HOWTO guide](../../../../operations/ebpf/enabling-ebpf.mdx). | true, false | false | -| BPFDisableUnprivileged /
FELIX_BPFDISABLEUNPRIVILEGED | If true, Felix sets the kernel.unprivileged_bpf_disabled sysctl to disable unprivileged use of BPF. This ensures that unprivileged users cannot access Calico's BPF maps and cannot insert their own BPF programs to interfere with the ones that $[prodname] installs. | true, false | true | -| BPFLogLevel /
FELIX_BPFLOGLEVEL | The log level used by the BPF programs. The logs are emitted to the BPF trace pipe, accessible with the command `tc exec BPF debug`. | Off,Info,Debug | Off | -| BPFDataIfacePattern /
FELIX_BPFDATAIFACEPATTERN | Controls which interfaces Felix should attach BPF programs to catch traffic to/from the external network. This needs to match the interfaces that Calico workload traffic flows over as well as any interfaces that handle incoming traffic to NodePorts and services from outside the cluster. It should not match the workload interfaces (usually named cali...).. | regular expression | `^(en[opsvx].\* | eth.\* | tunl0$ | wireguard.cali$)` | -| BPFConnectTimeLoadBalancingEnabled /
FELIX_BPFCONNECTTIMELOADBALANCINGENABLED | Controls whether Felix installs the connect-time load balancer. In the current release, the connect-time load balancer is required for the host to reach kubernetes services. | true,false | true | -| BPFExternalServiceMode /
FELIX_BPFEXTERNALSERVICEMODE | Controls how traffic from outside the cluster to NodePorts and ClusterIPs is handled. In Tunnel mode, packet is tunneled from the ingress host to the host with the backing pod and back again. In DSR mode, traffic is tunneled to the host with the backing pod and then returned directly; this requires a network that allows direct return. | Tunnel,DSR | Tunnel | -| BPFExtToServiceConnmark /
FELIX_BPFEXTTOSERVICECONNMARK | Controls a 32bit mark that is set on connections from an external client to a local service. This mark allows us to control how packets of that connection are routed within the host and how is routing interpreted by RPF check. | int | 0 | -| BPFKubeProxyIptablesCleanupEnabled /
FELIX_BPFKUBEPROXYIPTABLESCLEANUPENABLED | Controls whether Felix will clean up the iptables rules created by the Kubernetes `kube-proxy`; should only be enabled if `kube-proxy` is not running. | true,false | true | -| BPFKubeProxyMinSyncPeriod /
FELIX_BPFKUBEPROXYMINSYNCPERIOD | Controls the minimum time between dataplane updates for Felix's embedded `kube-proxy` implementation. | seconds | `1` | -| BPFKubeProxyEndpointSlicesEnabled /
FELIX_BPFKUBEPROXYENDPOINTSLICESENABLED | Controls whether Felix's embedded kube-proxy derives its services from Kubernetes' EndpointSlices resources. Using EndpointSlices is more efficient but it requires EndpointSlices support to be enabled at the Kubernetes API server. | true,false | false | -| BPFMapSizeConntrack /
FELIX_BPFMapSizeConntrack | Controls the size of the conntrack map. This map must be large enough to hold an entry for each active connection. Warning: changing the size of the conntrack map can cause disruption. | int | 512000 | -| BPFMapSizeNATFrontend /
FELIX_BPFMapSizeNATFrontend | Controls the size of the NAT frontend map. FrontendMap should be large enough to hold an entry for each nodeport, external IP and each port in each service. | int | 65536 | -| BPFMapSizeNATBackend /
FELIX_BPFMapSizeNATBackend | Controls the size of the NAT backend map. This is the total number of endpoints. This is mostly more than the size of the number of services. | int | 262144 | -| BPFMapSizeNATAffinity /
FELIX_BPFMapSizeNATAffinity | Controls the size of the NAT affinity map. | int | 65536 | -| BPFMapSizeIPSets /
FELIX_BPFMapSizeIPSets | Controls the size of the IPSets map. The IP sets map must be large enough to hold an entry for each endpoint matched by every selector in the source/destination matches in network policy. Selectors such as "all()" can result in large numbers of entries (one entry per endpoint in that case). | int | 1048576 | -| BPFMapSizeRoute /
FELIX_BPFMapSizeRoute | Controls the size of the route map. The routes map should be large enough to hold one entry per workload and a handful of entries per host (enough to cover its own IPs and tunnel IPs). | int | 262144 | -| BPFHostConntrackBypass /
FELIX_BPFHostConntrackBypass | Controls whether to bypass Linux conntrack in BPF mode for workloads and services. | true,false | true | -| BPFPolicyDebugEnabled /
FELIX_BPFPOLICYDEBUGENABLED | In eBPF dataplane mode, Felix records detailed information about the BPF policy programs, which can be examined with the calico-bpf command-line tool. | true, false | true | - -### Windows-specific configuration - -| Configuration parameter | Environment variable | Description | Schema | Default | -| ------------------------------- | ------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- | ------------------------------------------- | -| windowsFlowLogsFileDirectory |
FELIX_WINDOWSFLOWLOGSFILEDIRECTORY | Set the directory where flow logs files are stored on Windows nodes. This parameter only takes effect when `flowLogsFileEnabled` is set to `true`. | string | `c:\\TigeraCalico\\flowlogs` | -| windowsFlowLogsPositionFilePath |
FELIX_WINDOWSFLOWLOGSPOSITIONFILEPATH | Specify the position of the external pipeline that reads flow logs on Windows nodes. This parameter only takes effect when `FlowLogsDynamicAggregationEnabled` is set to `true`. | string | `c:\\TigeraCalico\\flowlogs\\flows.log.pos` | -| windowsStatsDumpFilePath |
FELIX_WINDOWSTATSDUMPFILEPATH | Specify the position of the file used for dumping flow log statistics on Windows nodes. Note this is an internal setting that users shouldn't need to modify. | string | `c:\\TigeraCalico\\stats\\dump` | -| WindowsDNSCacheFile |
FELIX_WINDOWSDNSCACHEFILE | Specify the name of the file that Felix uses to preserve learned DNS information when restarting. | string | `c:\\TigeraCalico\\felix-dns-cache.txt` | -| WindowsDNSExtraTTL |
FELIX_WINDOWSDNSEXTRATTL | Specify extra time in seconds to keep IPs and alias names that are learned from DNS, in addition to each name or IP's advertised TTL. | seconds | `120` | - -### Kubernetes-specific configuration - -| Configuration parameter | Environment variable | Description | Schema | -| ----------------------- | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | -| `KubeNodePortRanges` | `FELIX_KUBENODEPORTRANGES` | A list of port ranges that Felix should treat as Kubernetes node ports. Only when `kube-proxy` is configured to use IPVS mode: Felix assumes that traffic arriving at the host of one of these ports will ultimately be forwarded instead of being terminated by a host process. [Default: `30000:32767`] | Comma-delimited list of `
- ]
- expectedIPs: ["10.0.0.1"]
-EOF
-```
-
-:::note
-
-Felix tries to detect the correct hostname for a system. It logs
-out the value it has determined at start-of-day in the following
-format:
-`2015-10-20 17:42:09,813 \[INFO\]\[30149/5\] calico.felix.config 285: Parameter FelixHostname (Felix compute host hostname) has value 'my-hostname' read from None`
-The value (in this case `'my-hostname'`) needs to match the hostname
-used in etcd. Ideally, the host's system hostname should be set
-correctly but if that's not possible, the Felix value can be
-overridden with the FelixHostname configuration setting. See
-configuration for more details.
-
-:::
-
-Where `
- -operator.tigera.io/v1 - -
- -APIServer -
- -ApplicationLayer -
- -Authentication -
- -Compliance -
- -EgressGateway -
- -ImageSet -
- -Installation -
- -IntrusionDetection -
- -LogCollector -
- -LogStorage -
- -ManagementCluster -
- -ManagementClusterConnection -
- -Manager -
- -Monitor -
- -PacketCaptureAPI -
- -PolicyRecommendation -
- -TLSPassThroughRoute -
- -TLSTerminatedRoute -
- -Tenant -
- -TigeraStatus -
- A value of 0 disables pod startup delays. -
- ` is an optional list of security profiles
-to apply to the endpoint and labels contains a set of arbitrary
-key/value pairs that can be used in selector expressions.
-
-
-
-:::note
-
-When rendering security rules on other hosts, $[prodname] uses the
-`expectedIPs` field to resolve label selectors
-to IP addresses. If the `expectedIPs` field is omitted
-then security rules that use labels will fail to match
-this endpoint.
-Or, if you knew that the IP address should be 10.0.0.1, but not the name
-of the interface:
-
-:::
-
-```bash
-calicoctl create -f - <
- ]
- expectedIPs: ["10.0.0.1"]
-EOF
-```
-
-After you create host endpoint objects, Felix will start policing
-traffic to/from that interface. If you have no policy or profiles in
-place, then you should see traffic being dropped on the interface.
-
-:::note
-
-By default, $[prodname] has a failsafe in place that allows certain
-traffic such as ssh. See below for more details on
-disabling/configuring the failsafe rules.
-
-:::
-
-If you don't see traffic being dropped, check the hostname, IP address
-and (if used) the interface name in the configuration. If there was
-something wrong with the endpoint data, Felix will log a validation
-error at `WARNING` level and it will ignore the endpoint:
-
-A `grep` through the Felix logs for the string "Validation failed" should allow
-you to locate the error.
-
-```bash
-grep "Validation failed" /var/log/calico/felix.log
-```
-
-An example error follows.
-
-```
-2016-05-31 12:16:21,651 [WARNING][8657/3] calico.felix.fetcd 1017:
- Validation failed for host endpoint HostEndpointId
-Packages: -
--
-
operator.tigera.io/v1
--API Schema definitions for configuring the installation of Calico and Calico Enterprise -
-Resource Types: -APIServer
--APIServer installs the Tigera API server and related resources. At most one instance -of this resource is supported. It must be named “default” or “tigera-secure”. -
-| Field | -Description | -||
|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||
-
-kind-string - - |
-
-APIServer
- |
-||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||
-
-spec- - -APIServerSpec - - - - |
-
-
- -Specification of the desired state for the Tigera API server. - -- -
|
-||
-
-status- - -APIServerStatus - - - - |
-
-
- -Most recently observed status for the Tigera API server. - - - |
-
ApplicationLayer
--ApplicationLayer is the Schema for the applicationlayers API -
-| Field | -Description | -||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||
-
-kind-string - - |
-
-ApplicationLayer
- |
-||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||
-
-spec- - -ApplicationLayerSpec - - - - |
-
-
- - -
|
-||||||||||
-
-status- - -ApplicationLayerStatus - - - - |
-- - - | -
Authentication
--Authentication is the Schema for the authentications API -
-| Field | -Description | -||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||||||
-
-kind-string - - |
-
-Authentication
- |
-||||||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||||||
-
-spec- - -AuthenticationSpec - - - - |
-
-
- - -
|
-||||||||||||||
-
-status- - -AuthenticationStatus - - - - |
-- - - | -
Compliance
--Compliance installs the components required for Tigera compliance reporting. At most one instance -of this resource is supported. It must be named “tigera-secure”. -
-| Field | -Description | -||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||
-
-kind-string - - |
-
-Compliance
- |
-||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||
-
-spec- - -ComplianceSpec - - - - |
-
-
- -Specification of the desired state for Tigera compliance reporting. - -- -
|
-||||||||||
-
-status- - -ComplianceStatus - - - - |
-
-
- -Most recently observed state for Tigera compliance reporting. - - - |
-
EgressGateway
--EgressGateway is the Schema for the egressgateways API -
-| Field | -Description | -||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||||||
-
-kind-string - - |
-
-EgressGateway
- |
-||||||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||||||
-
-spec- - -EgressGatewaySpec - - - - |
-
-
- - -
|
-||||||||||||||
-
-status- - -EgressGatewayStatus - - - - |
-- - - | -
ImageSet
-
-ImageSet is used to specify image digests for the images that the operator deploys.
-The name of the ImageSet is expected to be in the format <variant>-<release>.
-The variant used is enterprise if the InstallationSpec Variant is
-TigeraSecureEnterprise otherwise it is calico.
-The release must match the version of the variant that the operator is built to deploy,
-this version can be obtained by passing the --version flag to the operator binary.
-
| Field | -Description | -||
|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||
-
-kind-string - - |
-
-ImageSet
- |
-||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||
-
-spec- - -ImageSetSpec - - - - |
-
-
- - -
|
-
Installation
--Installation configures an installation of Calico or Calico Enterprise. At most one instance -of this resource is supported. It must be named “default”. The Installation API installs core networking -and network policy components, and provides general install-time configuration. -
-| Field | -Description | -||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-
-kind-string - - |
-
-Installation
- |
-||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-
-spec- - -InstallationSpec - - - - |
-
-
- -Specification of the desired state for the Calico or Calico Enterprise installation. - -- -
|
-||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
-
-status- - -InstallationStatus - - - - |
-
-
- -Most recently observed state for the Calico or Calico Enterprise installation. - - - |
-
IntrusionDetection
--IntrusionDetection installs the components required for Tigera intrusion detection. At most one instance -of this resource is supported. It must be named “tigera-secure”. -
-| Field | -Description | -||||||
|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||
-
-kind-string - - |
-
-IntrusionDetection
- |
-||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||
-
-spec- - -IntrusionDetectionSpec - - - - |
-
-
- -Specification of the desired state for Tigera intrusion detection. - -- -
|
-||||||
-
-status- - -IntrusionDetectionStatus - - - - |
-
-
- -Most recently observed state for Tigera intrusion detection. - - - |
-
LogCollector
--LogCollector installs the components required for Tigera flow and DNS log collection. At most one instance -of this resource is supported. It must be named “tigera-secure”. When created, this installs fluentd on all nodes -configured to collect Tigera log data and export it to Tigera’s Elasticsearch cluster as well as any additionally configured destinations. -
-| Field | -Description | -||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||||
-
-kind-string - - |
-
-LogCollector
- |
-||||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||||
-
-spec- - -LogCollectorSpec - - - - |
-
-
- -Specification of the desired state for Tigera log collection. - -- -
|
-||||||||||||
-
-status- - -LogCollectorStatus - - - - |
-
-
- -Most recently observed state for Tigera log collection. - - - |
-
LogStorage
--LogStorage installs the components required for Tigera flow and DNS log storage. At most one instance -of this resource is supported. It must be named “tigera-secure”. When created, this installs an Elasticsearch cluster for use by -Calico Enterprise. -
-| Field | -Description | -||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||||||||||||
-
-kind-string - - |
-
-LogStorage
- |
-||||||||||||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||||||||||||
-
-spec- - -LogStorageSpec - - - - |
-
-
- -Specification of the desired state for Tigera log storage. - -- -
|
-||||||||||||||||||||
-
-status- - -LogStorageStatus - - - - |
-
-
- -Most recently observed state for Tigera log storage. - - - |
-
ManagementCluster
--The presence of ManagementCluster in your cluster, will configure it to be the management plane to which managed -clusters can connect. At most one instance of this resource is supported. It must be named “tigera-secure”. -
-| Field | -Description | -||||
|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||
-
-kind-string - - |
-
-ManagementCluster
- |
-||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||
-
-spec- - -ManagementClusterSpec - - - - |
-
-
- - -
|
-
ManagementClusterConnection
--ManagementClusterConnection represents a link between a managed cluster and a management cluster. At most one -instance of this resource is supported. It must be named “tigera-secure”. -
-| Field | -Description | -||||||
|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||
-
-kind-string - - |
-
-ManagementClusterConnection
- |
-||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||
-
-spec- - -ManagementClusterConnectionSpec - - - - |
-
-
- - -
|
-||||||
-
-status- - -ManagementClusterConnectionStatus - - - - |
-- - - | -
Manager
--Manager installs the Calico Enterprise manager graphical user interface. At most one instance -of this resource is supported. It must be named “tigera-secure”. -
-| Field | -Description | -||
|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||
-
-kind-string - - |
-
-Manager
- |
-||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||
-
-spec- - -ManagerSpec - - - - |
-
-
- -Specification of the desired state for the Calico Enterprise manager. - -- -
|
-||
-
-status- - -ManagerStatus - - - - |
-
-
- -Most recently observed state for the Calico Enterprise manager. - - - |
-
Monitor
--Monitor is the Schema for the monitor API. At most one instance -of this resource is supported. It must be named “tigera-secure”. -
-| Field | -Description | -||||||
|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||
-
-kind-string - - |
-
-Monitor
- |
-||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||
-
-spec- - -MonitorSpec - - - - |
-
-
- - -
|
-||||||
-
-status- - -MonitorStatus - - - - |
-- - - | -
PacketCaptureAPI
--PacketCaptureAPI is used to configure the resource requirement for PacketCaptureAPI deployment. It must be named “tigera-secure”. -
-| Field | -Description | -||
|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||
-
-kind-string - - |
-
-PacketCaptureAPI
- |
-||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||
-
-spec- - -PacketCaptureAPISpec - - - - |
-
-
- -Specification of the desired state for the PacketCaptureAPI. - -- -
|
-||
-
-status- - -PacketCaptureAPIStatus - - - - |
-
-
- -Most recently observed state for the PacketCaptureAPI. - - - |
-
PolicyRecommendation
--PolicyRecommendation is the Schema for the policy recommendation API. At most one instance -of this resource is supported. It must be named “tigera-secure”. -
-| Field | -Description | -||
|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||
-
-kind-string - - |
-
-PolicyRecommendation
- |
-||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||
-
-spec- - -PolicyRecommendationSpec - - - - |
-
-
- - -
|
-||
-
-status- - -PolicyRecommendationStatus - - - - |
-- - - | -
TLSPassThroughRoute
-| Field | -Description | -||||||
|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||
-
-kind-string - - |
-
-TLSPassThroughRoute
- |
-||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||
-
-spec- - -TLSPassThroughRouteSpec - - - - |
-
-
- -Dest is the destination URL - -- -
|
-
TLSTerminatedRoute
-| Field | -Description | -||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||||||
-
-kind-string - - |
-
-TLSTerminatedRoute
- |
-||||||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||||||
-
-spec- - -TLSTerminatedRouteSpec - - - - |
-
-
- - -
|
-
Tenant
--Tenant is the Schema for the tenants API -
-| Field | -Description | -||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-||||||||||||||||
-
-kind-string - - |
-
-Tenant
- |
-||||||||||||||||
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||||||||
-
-spec- - -TenantSpec - - - - |
-
-
- - -
|
-||||||||||||||||
-
-status- - -TenantStatus - - - - |
-- - - | -
TigeraStatus
--TigeraStatus represents the most recently observed status for Calico or a Calico Enterprise functional area. -
-| Field | -Description | -
|---|---|
-
-apiVersion-string - |
-
-
-
-operator.tigera.io/v1
-
-
- |
-
-
-kind-string - - |
-
-TigeraStatus
- |
-
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-
-
-spec- - -TigeraStatusSpec - - - - |
-
-
- - - |
-
-
-status- - -TigeraStatusStatus - - - - |
-- - - | -
APIServerDeployment
-- -(Appears on: -APIServerSpec) - -
--APIServerDeployment is the configuration for the API server Deployment. -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to the Deployment. - - - |
-
-
-spec- - -APIServerDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the API server Deployment. - -- - |
-
APIServerDeploymentContainer
-- -(Appears on: -APIServerDeploymentPodSpec) - -
--APIServerDeploymentContainer is an API server Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the API server Deployment container by name. -Supported values are: calico-apiserver, tigera-queryserver - - - |
-
-
-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 API server Deployment container’s resources. -If omitted, the API server Deployment will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
APIServerDeploymentInitContainer
-- -(Appears on: -APIServerDeploymentPodSpec) - -
--APIServerDeploymentInitContainer is an API server Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the API server Deployment init container by name. -Supported values are: calico-apiserver-certs-key-cert-provisioner - - - |
-
-
-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 API server Deployment init container’s resources. -If omitted, the API server Deployment will use its default value for this init container’s resources. - - - |
-
APIServerDeploymentPodSpec
-- -(Appears on: -APIServerDeploymentPodTemplateSpec) - -
--APIServerDeploymentDeploymentPodSpec is the API server Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]APIServerDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of API server init containers. -If specified, this overrides the specified API server Deployment init containers. -If omitted, the API server Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]APIServerDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of API server containers. -If specified, this overrides the specified API server Deployment containers. -If omitted, the API server Deployment will use its default values for its containers. - - - |
-
-
-affinity- - -Kubernetes core/v1.Affinity - - - - |
-
-
-(Optional)
- -Affinity is a group of affinity scheduling rules for the API server pods. -If specified, this overrides any affinity that may be set on the API server Deployment. -If omitted, the API server Deployment will use its default value for affinity. -WARNING: Please note that this field will override the default API server Deployment affinity. - - - |
-
-
-nodeSelector- -map[string]string - - - |
-
-
- -NodeSelector is the API server pod’s scheduling constraints. -If specified, each of the key/value pairs are added to the API server Deployment 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 API server Deployment -and each of this field’s key/value pairs are added to the API server Deployment nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If omitted, the API server Deployment will use its default value for nodeSelector. -WARNING: Please note that this field will modify the default API server Deployment nodeSelector. - - - |
-
-
-topologySpreadConstraints- - -[]Kubernetes core/v1.TopologySpreadConstraint - - - - |
-
-
-(Optional)
- -TopologySpreadConstraints describes how a group of pods ought to spread across topology -domains. Scheduler will schedule pods in a way which abides by the constraints. -All topologySpreadConstraints are ANDed. - - - |
-
-
-tolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -Tolerations is the API server pod’s tolerations. -If specified, this overrides any tolerations that may be set on the API server Deployment. -If omitted, the API server Deployment will use its default value for tolerations. -WARNING: Please note that this field will override the default API server Deployment tolerations. - - - |
-
APIServerDeploymentPodTemplateSpec
-- -(Appears on: -APIServerDeploymentSpec) - -
--APIServerDeploymentPodTemplateSpec is the API server Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. - - - |
-
-
-spec- - -APIServerDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the API server Deployment’s PodSpec. - -- - |
-
APIServerDeploymentSpec
-- -(Appears on: -APIServerDeployment) - -
--APIServerDeploymentSpec defines configuration for the API server Deployment. -
-| Field | -Description | -
|---|---|
-
-minReadySeconds- -int32 - - - |
-
-
-(Optional)
- -MinReadySeconds is the minimum number of seconds for which a newly created Deployment 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 API server Deployment. -If omitted, the API server Deployment will use its default value for minReadySeconds. - - - |
-
-
-template- - -APIServerDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the API server Deployment pod that will be created. - - - |
-
APIServerSpec
-- -(Appears on: -APIServer) - -
--APIServerSpec defines the desired state of Tigera API server. -
-| Field | -Description | -
|---|---|
-
-apiServerDeployment- - -APIServerDeployment - - - - |
-
-
- -APIServerDeployment configures the calico-apiserver (or tigera-apiserver in Enterprise) Deployment. If -used in conjunction with ControlPlaneNodeSelector or ControlPlaneTolerations, then these overrides -take precedence. - - - |
-
APIServerStatus
-- -(Appears on: -APIServer) - -
--APIServerStatus defines the observed state of Tigera API server. -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
AWSEgressGateway
-- -(Appears on: -EgressGatewaySpec) - -
--AWSEgressGateway defines the configurations for deploying EgressGateway in AWS -
-| Field | -Description | -
|---|---|
-
-nativeIP- - -NativeIP - - - - |
-
-
-(Optional)
- -NativeIP defines if EgressGateway is to use an AWS backed IPPool. -Default: Disabled - - - |
-
-
-elasticIPs- -[]string - - - |
-
-
-(Optional)
- -ElasticIPs defines the set of elastic IPs that can be used for Egress Gateway pods. -NativeIP must be Enabled if elastic IPs are set. - - - |
-
AdditionalLogSourceSpec
-- -(Appears on: -LogCollectorSpec) - -
-| Field | -Description | -
|---|---|
-
-eksCloudwatchLog- - -EksCloudwatchLogsSpec - - - - |
-
-
-(Optional)
- -If specified with EKS Provider in Installation, enables fetching EKS -audit logs. - - - |
-
AdditionalLogStoreSpec
-- -(Appears on: -LogCollectorSpec) - -
-| Field | -Description | -
|---|---|
-
-s3- - -S3StoreSpec - - - - |
-
-
-(Optional)
- -If specified, enables exporting of flow, audit, and DNS logs to Amazon S3 storage. - - - |
-
-
-syslog- - -SyslogStoreSpec - - - - |
-
-
-(Optional)
- -If specified, enables exporting of flow, audit, and DNS logs to syslog. - - - |
-
-
-splunk- - -SplunkStoreSpec - - - - |
-
-
-(Optional)
- -If specified, enables exporting of flow, audit, and DNS logs to splunk. - - - |
-
AlertManager
-- -(Appears on: -MonitorSpec) - -
-| Field | -Description | -
|---|---|
-
-spec- - -AlertManagerSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the Alertmanager. - -- - |
-
AlertManagerSpec
-- -(Appears on: -AlertManager) - -
-| Field | -Description | -
|---|---|
-
-resources- - -Kubernetes core/v1.ResourceRequirements - - - - |
-
-
- -Define resources requests and limits for single Pods. - - - |
-
AnomalyDetectionSpec
-- -(Appears on: -IntrusionDetectionSpec) - -
-| Field | -Description | -
|---|---|
-
-storageClassName- -string - - - |
-
-
-(Optional)
- -StorageClassName is now deprecated, and configuring it has no effect. - - - |
-
ApplicationLayerPolicyStatusType
-(string alias)
-- -(Appears on: -ApplicationLayerSpec) - -
-ApplicationLayerSpec
-- -(Appears on: -ApplicationLayer) - -
--ApplicationLayerSpec defines the desired state of ApplicationLayer -
-| Field | -Description | -
|---|---|
-
-webApplicationFirewall- - -WAFStatusType - - - - |
-
-
- -WebApplicationFirewall controls whether or not ModSecurity enforcement is enabled for the cluster. -When enabled, Services may opt-in to having ingress traffic examed by ModSecurity. - - - |
-
-
-logCollection- - -LogCollectionSpec - - - - |
-
-
- -Specification for application layer (L7) log collection. - - - |
-
-
-applicationLayerPolicy- - -ApplicationLayerPolicyStatusType - - - - |
-
-
- -Application Layer Policy controls whether or not ALP enforcement is enabled for the cluster. -When enabled, NetworkPolicies with HTTP Match rules may be defined to opt-in workloads for traffic enforcement on the application layer. - - - |
-
-
-envoy- - -EnvoySettings - - - - |
-
-
- -User-configurable settings for the Envoy proxy. - - - |
-
-
-l7LogCollectorDaemonSet- - -L7LogCollectorDaemonSet - - - - |
-
-
-(Optional)
- -L7LogCollectorDaemonSet configures the L7LogCollector DaemonSet. - - - |
-
ApplicationLayerStatus
-- -(Appears on: -ApplicationLayer) - -
--ApplicationLayerStatus defines the observed state of ApplicationLayer -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
AuthMethod
-(string alias)
-AuthenticationLDAP
-- -(Appears on: -AuthenticationSpec) - -
--AuthenticationLDAP is the configuration needed to setup LDAP. -
-| Field | -Description | -
|---|---|
-
-host- -string - - - |
-
-
- -The host and port of the LDAP server. Example: ad.example.com:636 - - - |
-
-
-startTLS- -bool - - - |
-
-
-(Optional)
- -StartTLS whether to enable the startTLS feature for establishing TLS on an existing LDAP session. -If true, the ldap:// protocol is used and then issues a StartTLS command, otherwise, connections will use -the ldaps:// protocol. - - - |
-
-
-userSearch- - -UserSearch - - - - |
-
-
- -User entry search configuration to match the credentials with a user. - - - |
-
-
-groupSearch- - -GroupSearch - - - - |
-
-
-(Optional)
- -Group search configuration to find the groups that a user is in. - - - |
-
AuthenticationOIDC
-- -(Appears on: -AuthenticationSpec) - -
--AuthenticationOIDC is the configuration needed to setup OIDC. -
-| Field | -Description | -
|---|---|
-
-issuerURL- -string - - - |
-
-
- -IssuerURL is the URL to the OIDC provider. - - - |
-
-
-usernameClaim- -string - - - |
-
-
- -UsernameClaim specifies which claim to use from the OIDC provider as the username. - - - |
-
-
-requestedScopes- -[]string - - - |
-
-
-(Optional)
- -RequestedScopes is a list of scopes to request from the OIDC provider. If not provided, the following scopes are -requested: [“openid”, “email”, “profile”, “groups”, “offline_access”]. - - - |
-
-
-usernamePrefix- -string - - - |
-
-
-(Optional)
- -Deprecated. Please use Authentication.Spec.UsernamePrefix instead. - - - |
-
-
-groupsClaim- -string - - - |
-
-
-(Optional)
- -GroupsClaim specifies which claim to use from the OIDC provider as the group. - - - |
-
-
-groupsPrefix- -string - - - |
-
-
-(Optional)
- -Deprecated. Please use Authentication.Spec.GroupsPrefix instead. - - - |
-
-
-emailVerification- - -EmailVerificationType - - - - |
-
-
-(Optional)
- -Some providers do not include the claim “email_verified” when there is no verification in the user enrollment -process or if they are acting as a proxy for another identity provider. By default those tokens are deemed invalid. -To skip this check, set the value to “InsecureSkip”. -Default: Verify - - - |
-
-
-promptTypes- - -[]PromptType - - - - |
-
-
-(Optional)
- -PromptTypes is an optional list of string values that specifies whether the identity provider prompts the end user -for re-authentication and consent. See the RFC for more information on prompt types: -https://openid.net/specs/openid-connect-core-1_0.html. -Default: “Consent” - - - |
-
-
-type- - -OIDCType - - - - |
-
-
-(Optional)
- -Default: “Dex” - - - |
-
AuthenticationOpenshift
-- -(Appears on: -AuthenticationSpec) - -
--AuthenticationOpenshift is the configuration needed to setup Openshift. -
-| Field | -Description | -
|---|---|
-
-issuerURL- -string - - - |
-
-
- -IssuerURL is the URL to the Openshift OAuth provider. Ex.: https://api.my-ocp-domain.com:6443 - - - |
-
AuthenticationSpec
-- -(Appears on: -Authentication) - -
--AuthenticationSpec defines the desired state of Authentication -
-| Field | -Description | -
|---|---|
-
-managerDomain- -string - - - |
-
-
- -ManagerDomain is the domain name of the Manager - - - |
-
-
-usernamePrefix- -string - - - |
-
-
-(Optional)
- -If specified, UsernamePrefix is prepended to each user obtained from the identity provider. Note that -Kibana does not support a user prefix, so this prefix is removed from Kubernetes User when translating log access -ClusterRoleBindings into Elastic. - - - |
-
-
-groupsPrefix- -string - - - |
-
-
-(Optional)
- -If specified, GroupsPrefix is prepended to each group obtained from the identity provider. Note that -Kibana does not support a groups prefix, so this prefix is removed from Kubernetes Groups when translating log access -ClusterRoleBindings into Elastic. - - - |
-
-
-oidc- - -AuthenticationOIDC - - - - |
-
-
-(Optional)
- -OIDC contains the configuration needed to setup OIDC authentication. - - - |
-
-
-openshift- - -AuthenticationOpenshift - - - - |
-
-
-(Optional)
- -Openshift contains the configuration needed to setup Openshift OAuth authentication. - - - |
-
-
-ldap- - -AuthenticationLDAP - - - - |
-
-
-(Optional)
- -LDAP contains the configuration needed to setup LDAP authentication. - - - |
-
-
-dexDeployment- - -DexDeployment - - - - |
-
-
-(Optional)
- -DexDeployment configures the Dex Deployment. - - - |
-
AuthenticationStatus
-- -(Appears on: -Authentication) - -
--AuthenticationStatus defines the observed state of Authentication -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
BGPOption
-(string alias)
-- -(Appears on: -CalicoNetworkSpec) - -
--BGPOption describes the mode of BGP to use. -
--One of: Enabled, Disabled -
-CAType
-(string alias)
-- -(Appears on: -ManagementClusterTLS) - -
--CAType specifies which verification method the tunnel client should use to verify the tunnel server’s identity. -
--One of: Tigera, Public -
-CNILogging
-- -(Appears on: -Logging) - -
-| Field | -Description | -
|---|---|
-
-logSeverity- - -LogLevel - - - - |
-
-
-(Optional)
- -Default: Info - - - |
-
-
-logFileMaxSize- -k8s.io/apimachinery/pkg/api/resource.Quantity - - - |
-
-
-(Optional)
- -Default: 100Mi - - - |
-
-
-logFileMaxAgeDays- -uint32 - - - |
-
-
-(Optional)
- -Default: 30 (days) - - - |
-
-
-logFileMaxCount- -uint32 - - - |
-
-
-(Optional)
- -Default: 10 - - - |
-
CNIPluginType
-(string alias)
-- -(Appears on: -CNISpec) - -
--CNIPluginType describes the type of CNI plugin used. -
--One of: Calico, GKE, AmazonVPC, AzureVNET -
-CNISpec
-- -(Appears on: -InstallationSpec) - -
--CNISpec contains configuration for the CNI plugin. -
-| Field | -Description | -
|---|---|
-
-type- - -CNIPluginType - - - - |
-
-
- -Specifies the CNI plugin that will be used in the Calico or Calico Enterprise installation. -* For KubernetesProvider GKE, this field defaults to GKE. -* For KubernetesProvider AKS, this field defaults to AzureVNET. -* For KubernetesProvider EKS, this field defaults to AmazonVPC. -* If aws-node daemonset exists in kube-system when the Installation resource is created, this field defaults to AmazonVPC. -* For all other cases this field defaults to Calico. - --For the value Calico, the CNI plugin binaries and CNI config will be installed as part of deployment, -for all other values the CNI plugin binaries and CNI config is a dependency that is expected -to be installed separately. - --Default: Calico - - - |
-
-
-ipam- - -IPAMSpec - - - - |
-
-
-(Optional)
- -IPAM specifies the pod IP address management that will be used in the Calico or -Calico Enterprise installation. - - - |
-
CSINodeDriverDaemonSet
-- -(Appears on: -InstallationSpec) - -
--CSINodeDriverDaemonSet is the configuration for the csi-node-driver DaemonSet. -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to the DaemonSet. - - - |
-
-
-spec- - -CSINodeDriverDaemonSetSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the csi-node-driver DaemonSet. - -- - |
-
CSINodeDriverDaemonSetContainer
-- -(Appears on: -CSINodeDriverDaemonSetPodSpec) - -
--CSINodeDriverDaemonSetContainer is a csi-node-driver DaemonSet container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the csi-node-driver DaemonSet container by name. -Supported values are: calico-csi, csi-node-driver-registrar. - - - |
-
-
-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 csi-node-driver DaemonSet container’s resources. -If omitted, the csi-node-driver DaemonSet will use its default value for this container’s resources. - - - |
-
CSINodeDriverDaemonSetPodSpec
-- -(Appears on: -CSINodeDriverDaemonSetPodTemplateSpec) - -
--CSINodeDriverDaemonSetPodSpec is the csi-node-driver DaemonSet’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-containers- - -[]CSINodeDriverDaemonSetContainer - - - - |
-
-
-(Optional)
- -Containers is a list of csi-node-driver containers. -If specified, this overrides the specified csi-node-driver DaemonSet containers. -If omitted, the csi-node-driver 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 csi-node-driver pods. -If specified, this overrides any affinity that may be set on the csi-node-driver DaemonSet. -If omitted, the csi-node-driver DaemonSet will use its default value for affinity. -WARNING: Please note that this field will override the default csi-node-driver DaemonSet affinity. - - - |
-
-
-nodeSelector- -map[string]string - - - |
-
-
-(Optional)
- -NodeSelector is the csi-node-driver pod’s scheduling constraints. -If specified, each of the key/value pairs are added to the csi-node-driver DaemonSet nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If omitted, the csi-node-driver DaemonSet will use its default value for nodeSelector. -WARNING: Please note that this field will modify the default csi-node-driver DaemonSet nodeSelector. - - - |
-
-
-tolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -Tolerations is the csi-node-driver pod’s tolerations. -If specified, this overrides any tolerations that may be set on the csi-node-driver DaemonSet. -If omitted, the csi-node-driver DaemonSet will use its default value for tolerations. -WARNING: Please note that this field will override the default csi-node-driver DaemonSet tolerations. - - - |
-
CSINodeDriverDaemonSetPodTemplateSpec
-- -(Appears on: -CSINodeDriverDaemonSetSpec) - -
--CSINodeDriverDaemonSetPodTemplateSpec is the csi-node-driver DaemonSet’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. - - - |
-
-
-spec- - -CSINodeDriverDaemonSetPodSpec - - - - |
-
-
-(Optional)
- -Spec is the csi-node-driver DaemonSet’s PodSpec. - -- - |
-
CSINodeDriverDaemonSetSpec
-- -(Appears on: -CSINodeDriverDaemonSet) - -
--CSINodeDriverDaemonSetSpec defines configuration for the csi-node-driver DaemonSet. -
-| Field | -Description | -
|---|---|
-
-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 csi-node-driver DaemonSet. -If omitted, the csi-node-driver DaemonSet will use its default value for minReadySeconds. - - - |
-
-
-template- - -CSINodeDriverDaemonSetPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the csi-node-driver DaemonSet pod that will be created. - - - |
-
CalicoKubeControllersDeployment
-- -(Appears on: -InstallationSpec, -TenantSpec) - -
--CalicoKubeControllersDeployment is the configuration for the calico-kube-controllers Deployment. -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to the Deployment. - - - |
-
-
-spec- - -CalicoKubeControllersDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the calico-kube-controllers Deployment. - -- - |
-
CalicoKubeControllersDeploymentContainer
-- -(Appears on: -CalicoKubeControllersDeploymentPodSpec) - -
--CalicoKubeControllersDeploymentContainer is a calico-kube-controllers Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the calico-kube-controllers Deployment container by name. -Supported values are: calico-kube-controllers, es-calico-kube-controllers - - - |
-
-
-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 calico-kube-controllers Deployment container’s resources. -If omitted, the calico-kube-controllers Deployment will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
CalicoKubeControllersDeploymentPodSpec
-- -(Appears on: -CalicoKubeControllersDeploymentPodTemplateSpec) - -
--CalicoKubeControllersDeploymentPodSpec is the calico-kube-controller Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-containers- - -[]CalicoKubeControllersDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of calico-kube-controllers containers. -If specified, this overrides the specified calico-kube-controllers Deployment containers. -If omitted, the calico-kube-controllers Deployment will use its default values for its containers. - - - |
-
-
-affinity- - -Kubernetes core/v1.Affinity - - - - |
-
-
-(Optional)
- -Affinity is a group of affinity scheduling rules for the calico-kube-controllers pods. -If specified, this overrides any affinity that may be set on the calico-kube-controllers Deployment. -If omitted, the calico-kube-controllers Deployment will use its default value for affinity. -WARNING: Please note that this field will override the default calico-kube-controllers Deployment affinity. - - - |
-
-
-nodeSelector- -map[string]string - - - |
-
-
- -NodeSelector is the calico-kube-controllers pod’s scheduling constraints. -If specified, each of the key/value pairs are added to the calico-kube-controllers Deployment 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 calico-kube-controllers Deployment -and each of this field’s key/value pairs are added to the calico-kube-controllers Deployment nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If omitted, the calico-kube-controllers Deployment will use its default value for nodeSelector. -WARNING: Please note that this field will modify the default calico-kube-controllers Deployment nodeSelector. - - - |
-
-
-tolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -Tolerations is the calico-kube-controllers pod’s tolerations. -If specified, this overrides any tolerations that may be set on the calico-kube-controllers Deployment. -If omitted, the calico-kube-controllers Deployment will use its default value for tolerations. -WARNING: Please note that this field will override the default calico-kube-controllers Deployment tolerations. - - - |
-
CalicoKubeControllersDeploymentPodTemplateSpec
-- -(Appears on: -CalicoKubeControllersDeploymentSpec) - -
--CalicoKubeControllersDeploymentPodTemplateSpec is the calico-kube-controllers Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. - - - |
-
-
-spec- - -CalicoKubeControllersDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the calico-kube-controllers Deployment’s PodSpec. - -- - |
-
CalicoKubeControllersDeploymentSpec
-- -(Appears on: -CalicoKubeControllersDeployment) - -
--CalicoKubeControllersDeploymentSpec defines configuration for the calico-kube-controllers Deployment. -
-| Field | -Description | -
|---|---|
-
-minReadySeconds- -int32 - - - |
-
-
-(Optional)
- -MinReadySeconds is the minimum number of seconds for which a newly created Deployment 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 calico-kube-controllers Deployment. -If omitted, the calico-kube-controllers Deployment will use its default value for minReadySeconds. - - - |
-
-
-template- - -CalicoKubeControllersDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the calico-kube-controllers Deployment pod that will be created. - - - |
-
CalicoNetworkSpec
-- -(Appears on: -InstallationSpec) - -
--CalicoNetworkSpec specifies configuration options for Calico provided pod networking. -
-| Field | -Description | -
|---|---|
-
-linuxDataplane- - -LinuxDataplaneOption - - - - |
-
-
-(Optional)
- -LinuxDataplane is used to select the dataplane used for Linux nodes. In particular, it -causes the operator to add required mounts and environment variables for the particular dataplane. -If not specified, iptables mode is used. -Default: Iptables - - - |
-
-
-windowsDataplane- - -WindowsDataplaneOption - - - - |
-
-
-(Optional)
- -WindowsDataplane is used to select the dataplane used for Windows nodes. In particular, it -causes the operator to add required mounts and environment variables for the particular dataplane. -If not specified, it is disabled and the operator will not render the Calico Windows nodes daemonset. -Default: Disabled - - - |
-
-
-bgp- - -BGPOption - - - - |
-
-
-(Optional)
- -BGP configures whether or not to enable Calico’s BGP capabilities. - - - |
-
-
-ipPools- - -[]IPPool - - - - |
-
-
-(Optional)
- -IPPools contains a list of IP pools to create if none exist. At most one IP pool of each -address family may be specified. If omitted, a single pool will be configured if needed. - - - |
-
-
-mtu- -int32 - - - |
-
-
-(Optional)
- -MTU specifies the maximum transmission unit to use on the pod network. -If not specified, Calico will perform MTU auto-detection based on the cluster network. - - - |
-
-
-nodeAddressAutodetectionV4- - -NodeAddressAutodetection - - - - |
-
-
-(Optional)
- -NodeAddressAutodetectionV4 specifies an approach to automatically detect node IPv4 addresses. If not specified, -will use default auto-detection settings to acquire an IPv4 address for each node. - - - |
-
-
-nodeAddressAutodetectionV6- - -NodeAddressAutodetection - - - - |
-
-
-(Optional)
- -NodeAddressAutodetectionV6 specifies an approach to automatically detect node IPv6 addresses. If not specified, -IPv6 addresses will not be auto-detected. - - - |
-
-
-hostPorts- - -HostPortsType - - - - |
-
-
-(Optional)
- -HostPorts configures whether or not Calico will support Kubernetes HostPorts. Valid only when using the Calico CNI plugin. -Default: Enabled - - - |
-
-
-multiInterfaceMode- - -MultiInterfaceMode - - - - |
-
-
-(Optional)
- -MultiInterfaceMode configures what will configure multiple interface per pod. Only valid for Calico Enterprise installations -using the Calico CNI plugin. -Default: None - - - |
-
-
-containerIPForwarding- - -ContainerIPForwardingType - - - - |
-
-
-(Optional)
- -ContainerIPForwarding configures whether ip forwarding will be enabled for containers in the CNI configuration. -Default: Disabled - - - |
-
-
-sysctl- - -[]Sysctl - - - - |
-
-
-(Optional)
- -Sysctl configures sysctl parameters for tuning plugin - - - |
-
-
-linuxPolicySetupTimeoutSeconds- -int32 - - - |
-
-
-(Optional)
- -LinuxPolicySetupTimeoutSeconds delays new pods from running containers -until their policy has been programmed in the dataplane. -The specified delay defines the maximum amount of time -that the Calico CNI plugin will wait for policy to be programmed. - --Only applies to pods created on Linux nodes. - -
-Default: 0 - - - |
-
CalicoNodeDaemonSet
-- -(Appears on: -InstallationSpec) - -
--CalicoNodeDaemonSet is the configuration for the calico-node DaemonSet. -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to the DaemonSet. - - - |
-
-
-spec- - -CalicoNodeDaemonSetSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the calico-node DaemonSet. - -- - |
-
CalicoNodeDaemonSetContainer
-- -(Appears on: -CalicoNodeDaemonSetPodSpec) - -
--CalicoNodeDaemonSetContainer is a calico-node DaemonSet container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the calico-node DaemonSet container by name. -Supported values are: calico-node - - - |
-
-
-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 calico-node DaemonSet container’s resources. -If omitted, the calico-node DaemonSet will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
CalicoNodeDaemonSetInitContainer
-- -(Appears on: -CalicoNodeDaemonSetPodSpec) - -
--CalicoNodeDaemonSetInitContainer is a calico-node DaemonSet init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the calico-node DaemonSet init container by name. -Supported values are: install-cni, hostpath-init, flexvol-driver, mount-bpffs, node-certs-key-cert-provisioner, calico-node-prometheus-server-tls-key-cert-provisioner - - - |
-
-
-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 calico-node DaemonSet init container’s resources. -If omitted, the calico-node DaemonSet will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
CalicoNodeDaemonSetPodSpec
-- -(Appears on: -CalicoNodeDaemonSetPodTemplateSpec) - -
--CalicoNodeDaemonSetPodSpec is the calico-node DaemonSet’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]CalicoNodeDaemonSetInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of calico-node init containers. -If specified, this overrides the specified calico-node DaemonSet init containers. -If omitted, the calico-node DaemonSet will use its default values for its init containers. - - - |
-
-
-containers- - -[]CalicoNodeDaemonSetContainer - - - - |
-
-
-(Optional)
- -Containers is a list of calico-node containers. -If specified, this overrides the specified calico-node DaemonSet containers. -If omitted, the calico-node 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 calico-node pods. -If specified, this overrides any affinity that may be set on the calico-node DaemonSet. -If omitted, the calico-node DaemonSet will use its default value for affinity. -WARNING: Please note that this field will override the default calico-node DaemonSet affinity. - - - |
-
-
-nodeSelector- -map[string]string - - - |
-
-
-(Optional)
- -NodeSelector is the calico-node pod’s scheduling constraints. -If specified, each of the key/value pairs are added to the calico-node DaemonSet nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If omitted, the calico-node DaemonSet will use its default value for nodeSelector. -WARNING: Please note that this field will modify the default calico-node DaemonSet nodeSelector. - - - |
-
-
-tolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -Tolerations is the calico-node pod’s tolerations. -If specified, this overrides any tolerations that may be set on the calico-node DaemonSet. -If omitted, the calico-node DaemonSet will use its default value for tolerations. -WARNING: Please note that this field will override the default calico-node DaemonSet tolerations. - - - |
-
CalicoNodeDaemonSetPodTemplateSpec
-- -(Appears on: -CalicoNodeDaemonSetSpec) - -
--CalicoNodeDaemonSetPodTemplateSpec is the calico-node DaemonSet’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. - - - |
-
-
-spec- - -CalicoNodeDaemonSetPodSpec - - - - |
-
-
-(Optional)
- -Spec is the calico-node DaemonSet’s PodSpec. - -- - |
-
CalicoNodeDaemonSetSpec
-- -(Appears on: -CalicoNodeDaemonSet) - -
--CalicoNodeDaemonSetSpec defines configuration for the calico-node DaemonSet. -
-| Field | -Description | -
|---|---|
-
-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 calico-node DaemonSet. -If omitted, the calico-node DaemonSet will use its default value for minReadySeconds. - - - |
-
-
-template- - -CalicoNodeDaemonSetPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the calico-node DaemonSet pod that will be created. - - - |
-
CalicoNodeWindowsDaemonSet
-- -(Appears on: -InstallationSpec) - -
--CalicoNodeWindowsDaemonSet is the configuration for the calico-node-windows DaemonSet. -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to the DaemonSet. - - - |
-
-
-spec- - -CalicoNodeWindowsDaemonSetSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the calico-node-windows DaemonSet. - -- - |
-
CalicoNodeWindowsDaemonSetContainer
-- -(Appears on: -CalicoNodeWindowsDaemonSetPodSpec) - -
--CalicoNodeWindowsDaemonSetContainer is a calico-node-windows DaemonSet container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the calico-node-windows DaemonSet container by name. -Supported values are: calico-node-windows - - - |
-
-
-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 calico-node-windows DaemonSet container’s resources. -If omitted, the calico-node-windows DaemonSet will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
CalicoNodeWindowsDaemonSetInitContainer
-- -(Appears on: -CalicoNodeWindowsDaemonSetPodSpec) - -
--CalicoNodeWindowsDaemonSetInitContainer is a calico-node-windows DaemonSet init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the calico-node-windows DaemonSet init container by name. -Supported values are: install-cni;hostpath-init, flexvol-driver, mount-bpffs, node-certs-key-cert-provisioner, calico-node-windows-prometheus-server-tls-key-cert-provisioner - - - |
-
-
-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 calico-node-windows DaemonSet init container’s resources. -If omitted, the calico-node-windows DaemonSet will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
CalicoNodeWindowsDaemonSetPodSpec
-- -(Appears on: -CalicoNodeWindowsDaemonSetPodTemplateSpec) - -
--CalicoNodeWindowsDaemonSetPodSpec is the calico-node-windows DaemonSet’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]CalicoNodeWindowsDaemonSetInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of calico-node-windows init containers. -If specified, this overrides the specified calico-node-windows DaemonSet init containers. -If omitted, the calico-node-windows DaemonSet will use its default values for its init containers. - - - |
-
-
-containers- - -[]CalicoNodeWindowsDaemonSetContainer - - - - |
-
-
-(Optional)
- -Containers is a list of calico-node-windows containers. -If specified, this overrides the specified calico-node-windows DaemonSet containers. -If omitted, the calico-node-windows 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 calico-node-windows pods. -If specified, this overrides any affinity that may be set on the calico-node-windows DaemonSet. -If omitted, the calico-node-windows DaemonSet will use its default value for affinity. -WARNING: Please note that this field will override the default calico-node-windows DaemonSet affinity. - - - |
-
-
-nodeSelector- -map[string]string - - - |
-
-
-(Optional)
- -NodeSelector is the calico-node-windows pod’s scheduling constraints. -If specified, each of the key/value pairs are added to the calico-node-windows DaemonSet nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If omitted, the calico-node-windows DaemonSet will use its default value for nodeSelector. -WARNING: Please note that this field will modify the default calico-node-windows DaemonSet nodeSelector. - - - |
-
-
-tolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -Tolerations is the calico-node-windows pod’s tolerations. -If specified, this overrides any tolerations that may be set on the calico-node-windows DaemonSet. -If omitted, the calico-node-windows DaemonSet will use its default value for tolerations. -WARNING: Please note that this field will override the default calico-node-windows DaemonSet tolerations. - - - |
-
CalicoNodeWindowsDaemonSetPodTemplateSpec
-- -(Appears on: -CalicoNodeWindowsDaemonSetSpec) - -
--CalicoNodeWindowsDaemonSetPodTemplateSpec is the calico-node-windows DaemonSet’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. - - - |
-
-
-spec- - -CalicoNodeWindowsDaemonSetPodSpec - - - - |
-
-
-(Optional)
- -Spec is the calico-node-windows DaemonSet’s PodSpec. - -- - |
-
CalicoNodeWindowsDaemonSetSpec
-- -(Appears on: -CalicoNodeWindowsDaemonSet) - -
--CalicoNodeWindowsDaemonSetSpec defines configuration for the calico-node-windows DaemonSet. -
-| Field | -Description | -
|---|---|
-
-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 calico-node-windows DaemonSet. -If omitted, the calico-node-windows DaemonSet will use its default value for minReadySeconds. - - - |
-
-
-template- - -CalicoNodeWindowsDaemonSetPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the calico-node-windows DaemonSet pod that will be created. - - - |
-
CalicoWindowsUpgradeDaemonSet
-- -(Appears on: -InstallationSpec) - -
--Deprecated. The CalicoWindowsUpgradeDaemonSet is deprecated and will be removed from the API in the future. -CalicoWindowsUpgradeDaemonSet is the configuration for the calico-windows-upgrade DaemonSet. -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to the Deployment. - - - |
-
-
-spec- - -CalicoWindowsUpgradeDaemonSetSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the calico-windows-upgrade DaemonSet. - -- - |
-
CalicoWindowsUpgradeDaemonSetContainer
-- -(Appears on: -CalicoWindowsUpgradeDaemonSetPodSpec) - -
--CalicoWindowsUpgradeDaemonSetContainer is a calico-windows-upgrade DaemonSet container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the calico-windows-upgrade 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 calico-windows-upgrade DaemonSet container’s resources. -If omitted, the calico-windows-upgrade DaemonSet will use its default value for this container’s resources. - - - |
-
CalicoWindowsUpgradeDaemonSetPodSpec
-- -(Appears on: -CalicoWindowsUpgradeDaemonSetPodTemplateSpec) - -
--CalicoWindowsUpgradeDaemonSetPodSpec is the calico-windows-upgrade DaemonSet’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-containers- - -[]CalicoWindowsUpgradeDaemonSetContainer - - - - |
-
-
-(Optional)
- -Containers is a list of calico-windows-upgrade containers. -If specified, this overrides the specified calico-windows-upgrade DaemonSet containers. -If omitted, the calico-windows-upgrade 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 calico-windows-upgrade pods. -If specified, this overrides any affinity that may be set on the calico-windows-upgrade DaemonSet. -If omitted, the calico-windows-upgrade DaemonSet will use its default value for affinity. -WARNING: Please note that this field will override the default calico-windows-upgrade DaemonSet affinity. - - - |
-
-
-nodeSelector- -map[string]string - - - |
-
-
-(Optional)
- -NodeSelector is the calico-windows-upgrade pod’s scheduling constraints. -If specified, each of the key/value pairs are added to the calico-windows-upgrade DaemonSet nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If omitted, the calico-windows-upgrade DaemonSet will use its default value for nodeSelector. -WARNING: Please note that this field will modify the default calico-windows-upgrade DaemonSet nodeSelector. - - - |
-
-
-tolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -Tolerations is the calico-windows-upgrade pod’s tolerations. -If specified, this overrides any tolerations that may be set on the calico-windows-upgrade DaemonSet. -If omitted, the calico-windows-upgrade DaemonSet will use its default value for tolerations. -WARNING: Please note that this field will override the default calico-windows-upgrade DaemonSet tolerations. - - - |
-
CalicoWindowsUpgradeDaemonSetPodTemplateSpec
-- -(Appears on: -CalicoWindowsUpgradeDaemonSetSpec) - -
--CalicoWindowsUpgradeDaemonSetPodTemplateSpec is the calico-windows-upgrade DaemonSet’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. - - - |
-
-
-spec- - -CalicoWindowsUpgradeDaemonSetPodSpec - - - - |
-
-
-(Optional)
- -Spec is the calico-windows-upgrade DaemonSet’s PodSpec. - -- - |
-
CalicoWindowsUpgradeDaemonSetSpec
-- -(Appears on: -CalicoWindowsUpgradeDaemonSet) - -
--CalicoWindowsUpgradeDaemonSetSpec defines configuration for the calico-windows-upgrade DaemonSet. -
-| Field | -Description | -
|---|---|
-
-minReadySeconds- -int32 - - - |
-
-
-(Optional)
- -MinReadySeconds is the minimum number of seconds for which a newly created Deployment 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 calico-windows-upgrade DaemonSet. -If omitted, the calico-windows-upgrade DaemonSet will use its default value for minReadySeconds. - - - |
-
-
-template- - -CalicoWindowsUpgradeDaemonSetPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the calico-windows-upgrade DaemonSet pod that will be created. - - - |
-
CertificateManagement
-- -(Appears on: -InstallationSpec) - -
--CertificateManagement configures pods to submit a CertificateSigningRequest to the certificates.k8s.io/v1beta1 API in order -to obtain TLS certificates. This feature requires that you bring your own CSR signing and approval process, otherwise -pods will be stuck during initialization. -
-| Field | -Description | -
|---|---|
-
-caCert- -[]byte - - - |
-
-
- -Certificate of the authority that signs the CertificateSigningRequests in PEM format. - - - |
-
-
-signerName- -string - - - |
-
-
-
-When a CSR is issued to the certificates.k8s.io API, the signerName is added to the request in order to accommodate for clusters
-with multiple signers.
-Must be formatted as: |
-
-
-keyAlgorithm- -string - - - |
-
-
-(Optional)
- -Specify the algorithm used by pods to generate a key pair that is associated with the X.509 certificate request. -Default: RSAWithSize2048 - - - |
-
-
-signatureAlgorithm- -string - - - |
-
-
-(Optional)
- -Specify the algorithm used for the signature of the X.509 certificate request. -Default: SHA256WithRSA - - - |
-
CollectProcessPathOption
-(string alias)
-- -(Appears on: -LogCollectorSpec) - -
-CommonPrometheusFields
-- -(Appears on: -PrometheusSpec) - -
-| Field | -Description | -
|---|---|
-
-containers- - -[]PrometheusContainer - - - - |
-
-
-(Optional)
- -Containers is a list of Prometheus containers. -If specified, this overrides the specified Prometheus Deployment containers. -If omitted, the Prometheus Deployment will use its default values for its containers. - - - |
-
-
-resources- - -Kubernetes core/v1.ResourceRequirements - - - - |
-
-
- -Define resources requests and limits for single Pods. - - - |
-
ComplianceBenchmarkerDaemonSet
-- -(Appears on: -ComplianceSpec) - -
--ComplianceBenchmarkerDaemonSet is the configuration for the Compliance Benchmarker DaemonSet. -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceBenchmarkerDaemonSetSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the Compliance Benchmarker DaemonSet. - -- - |
-
ComplianceBenchmarkerDaemonSetContainer
-- -(Appears on: -ComplianceBenchmarkerDaemonSetPodSpec) - -
--ComplianceBenchmarkerDaemonSetContainer is a Compliance Benchmarker DaemonSet container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Compliance Benchmarker DaemonSet container by name. -Supported values are: compliance-benchmarker - - - |
-
-
-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 Compliance Benchmarker DaemonSet container’s resources. -If omitted, the Compliance Benchmarker DaemonSet will use its default value for this container’s resources. - - - |
-
ComplianceBenchmarkerDaemonSetInitContainer
-- -(Appears on: -ComplianceBenchmarkerDaemonSetPodSpec) - -
--ComplianceBenchmarkerDaemonSetInitContainer is a Compliance Benchmarker DaemonSet init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Compliance Benchmarker DaemonSet init container by name. -Supported values are: tigera-compliance-benchmarker-tls-key-cert-provisioner - - - |
-
-
-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 Compliance Benchmarker DaemonSet init container’s resources. -If omitted, the Compliance Benchmarker DaemonSet will use its default value for this init container’s resources. - - - |
-
ComplianceBenchmarkerDaemonSetPodSpec
-- -(Appears on: -ComplianceBenchmarkerDaemonSetPodTemplateSpec) - -
--ComplianceBenchmarkerDaemonSetPodSpec is the Compliance Benchmarker DaemonSet’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]ComplianceBenchmarkerDaemonSetInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of Compliance benchmark init containers. -If specified, this overrides the specified Compliance Benchmarker DaemonSet init containers. -If omitted, the Compliance Benchmarker DaemonSet will use its default values for its init containers. - - - |
-
-
-containers- - -[]ComplianceBenchmarkerDaemonSetContainer - - - - |
-
-
-(Optional)
- -Containers is a list of Compliance benchmark containers. -If specified, this overrides the specified Compliance Benchmarker DaemonSet containers. -If omitted, the Compliance Benchmarker DaemonSet will use its default values for its containers. - - - |
-
ComplianceBenchmarkerDaemonSetPodTemplateSpec
-- -(Appears on: -ComplianceBenchmarkerDaemonSetSpec) - -
--ComplianceBenchmarkerDaemonSetPodTemplateSpec is the Compliance Benchmarker DaemonSet’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceBenchmarkerDaemonSetPodSpec - - - - |
-
-
-(Optional)
- -Spec is the Compliance Benchmarker DaemonSet’s PodSpec. - -- - |
-
ComplianceBenchmarkerDaemonSetSpec
-- -(Appears on: -ComplianceBenchmarkerDaemonSet) - -
--ComplianceBenchmarkerDaemonSetSpec defines configuration for the Compliance Benchmarker DaemonSet. -
-| Field | -Description | -
|---|---|
-
-template- - -ComplianceBenchmarkerDaemonSetPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the Compliance Benchmarker DaemonSet pod that will be created. - - - |
-
ComplianceControllerDeployment
-- -(Appears on: -ComplianceSpec) - -
--ComplianceControllerDeployment is the configuration for the compliance controller Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceControllerDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the compliance controller Deployment. - -- - |
-
ComplianceControllerDeploymentContainer
-- -(Appears on: -ComplianceControllerDeploymentPodSpec) - -
--ComplianceControllerDeploymentContainer is a compliance controller Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the compliance controller Deployment container by name. -Supported values are: compliance-controller - - - |
-
-
-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 compliance controller Deployment container’s resources. -If omitted, the compliance controller Deployment will use its default value for this container’s resources. - - - |
-
ComplianceControllerDeploymentInitContainer
-- -(Appears on: -ComplianceControllerDeploymentPodSpec) - -
--ComplianceControllerDeploymentInitContainer is a compliance controller Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the compliance controller Deployment init container by name. -Supported values are: tigera-compliance-controller-tls-key-cert-provisioner - - - |
-
-
-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 compliance controller Deployment init container’s resources. -If omitted, the compliance controller Deployment will use its default value for this init container’s resources. - - - |
-
ComplianceControllerDeploymentPodSpec
-- -(Appears on: -ComplianceControllerDeploymentPodTemplateSpec) - -
--ComplianceControllerDeploymentPodSpec is the compliance controller Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]ComplianceControllerDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of compliance controller init containers. -If specified, this overrides the specified compliance controller Deployment init containers. -If omitted, the compliance controller Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]ComplianceControllerDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of compliance controller containers. -If specified, this overrides the specified compliance controller Deployment containers. -If omitted, the compliance controller Deployment will use its default values for its containers. - - - |
-
ComplianceControllerDeploymentPodTemplateSpec
-- -(Appears on: -ComplianceControllerDeploymentSpec) - -
--ComplianceControllerDeploymentPodTemplateSpec is the compliance controller Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceControllerDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the compliance controller Deployment’s PodSpec. - -- - |
-
ComplianceControllerDeploymentSpec
-- -(Appears on: -ComplianceControllerDeployment) - -
--ComplianceControllerDeploymentSpec defines configuration for the compliance controller Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -ComplianceControllerDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the compliance controller Deployment pod that will be created. - - - |
-
ComplianceReporterPodSpec
-- -(Appears on: -ComplianceReporterPodTemplateSpec) - -
--ComplianceReporterPodSpec is the ComplianceReporter PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]ComplianceReporterPodTemplateInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of ComplianceReporter PodSpec init containers. -If specified, this overrides the specified ComplianceReporter PodSpec init containers. -If omitted, the ComplianceServer Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]ComplianceReporterPodTemplateContainer - - - - |
-
-
-(Optional)
- -Containers is a list of ComplianceServer containers. -If specified, this overrides the specified ComplianceReporter PodSpec containers. -If omitted, the ComplianceServer Deployment will use its default values for its containers. - - - |
-
ComplianceReporterPodTemplate
-- -(Appears on: -ComplianceSpec) - -
--ComplianceReporterPodTemplate is the configuration for the ComplianceReporter PodTemplate. -
-| Field | -Description | -
|---|---|
-
-template- - -ComplianceReporterPodTemplateSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the ComplianceReporter PodTemplateSpec. - - - |
-
ComplianceReporterPodTemplateContainer
-- -(Appears on: -ComplianceReporterPodSpec) - -
--ComplianceReporterPodTemplateContainer is a ComplianceServer Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the ComplianceServer Deployment container by name. -Supported values are: reporter - - - |
-
-
-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 ComplianceServer Deployment container’s resources. -If omitted, the ComplianceServer Deployment will use its default value for this container’s resources. - - - |
-
ComplianceReporterPodTemplateInitContainer
-- -(Appears on: -ComplianceReporterPodSpec) - -
--ComplianceReporterPodTemplateInitContainer is a ComplianceServer Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the ComplianceReporter PodSpec init container by name. -Supported values are: tigera-compliance-reporter-tls-key-cert-provisioner - - - |
-
-
-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 ComplianceReporter PodSpec init container’s resources. -If omitted, the ComplianceServer Deployment will use its default value for this init container’s resources. - - - |
-
ComplianceReporterPodTemplateSpec
-- -(Appears on: -ComplianceReporterPodTemplate) - -
--ComplianceReporterPodTemplateSpec is the ComplianceReporter PodTemplateSpec. -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceReporterPodSpec - - - - |
-
-
-(Optional)
- -Spec is the ComplianceReporter PodTemplate’s PodSpec. - -- - |
-
ComplianceServerDeployment
-- -(Appears on: -ComplianceSpec) - -
--ComplianceServerDeployment is the configuration for the ComplianceServer Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceServerDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the ComplianceServer Deployment. - -- - |
-
ComplianceServerDeploymentContainer
-- -(Appears on: -ComplianceServerDeploymentPodSpec) - -
--ComplianceServerDeploymentContainer is a ComplianceServer Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the ComplianceServer Deployment container by name. -Supported values are: compliance-server - - - |
-
-
-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 ComplianceServer Deployment container’s resources. -If omitted, the ComplianceServer Deployment will use its default value for this container’s resources. - - - |
-
ComplianceServerDeploymentInitContainer
-- -(Appears on: -ComplianceServerDeploymentPodSpec) - -
--ComplianceServerDeploymentInitContainer is a ComplianceServer Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the ComplianceServer Deployment init container by name. -Supported values are: tigera-compliance-server-tls-key-cert-provisioner - - - |
-
-
-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 ComplianceServer Deployment init container’s resources. -If omitted, the ComplianceServer Deployment will use its default value for this init container’s resources. - - - |
-
ComplianceServerDeploymentPodSpec
-- -(Appears on: -ComplianceServerDeploymentPodTemplateSpec) - -
--ComplianceServerDeploymentPodSpec is the ComplianceServer Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]ComplianceServerDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of ComplianceServer init containers. -If specified, this overrides the specified ComplianceServer Deployment init containers. -If omitted, the ComplianceServer Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]ComplianceServerDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of ComplianceServer containers. -If specified, this overrides the specified ComplianceServer Deployment containers. -If omitted, the ComplianceServer Deployment will use its default values for its containers. - - - |
-
ComplianceServerDeploymentPodTemplateSpec
-- -(Appears on: -ComplianceServerDeploymentSpec) - -
--ComplianceServerDeploymentPodTemplateSpec is the ComplianceServer Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceServerDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the ComplianceServer Deployment’s PodSpec. - -- - |
-
ComplianceServerDeploymentSpec
-- -(Appears on: -ComplianceServerDeployment) - -
--ComplianceServerDeploymentSpec defines configuration for the ComplianceServer Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -ComplianceServerDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the ComplianceServer Deployment pod that will be created. - - - |
-
ComplianceSnapshotterDeployment
-- -(Appears on: -ComplianceSpec) - -
--ComplianceSnapshotterDeployment is the configuration for the compliance snapshotter Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceSnapshotterDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the compliance snapshotter Deployment. - -- - |
-
ComplianceSnapshotterDeploymentContainer
-- -(Appears on: -ComplianceSnapshotterDeploymentPodSpec) - -
--ComplianceSnapshotterDeploymentContainer is a compliance snapshotter Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the compliance snapshotter Deployment container by name. -Supported values are: compliance-snapshotter - - - |
-
-
-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 compliance snapshotter Deployment container’s resources. -If omitted, the compliance snapshotter Deployment will use its default value for this container’s resources. - - - |
-
ComplianceSnapshotterDeploymentInitContainer
-- -(Appears on: -ComplianceSnapshotterDeploymentPodSpec) - -
--ComplianceSnapshotterDeploymentInitContainer is a compliance snapshotter Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the compliance snapshotter Deployment init container by name. -Supported values are: tigera-compliance-snapshotter-tls-key-cert-provisioner - - - |
-
-
-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 compliance snapshotter Deployment init container’s resources. -If omitted, the compliance snapshotter Deployment will use its default value for this init container’s resources. - - - |
-
ComplianceSnapshotterDeploymentPodSpec
-- -(Appears on: -ComplianceSnapshotterDeploymentPodTemplateSpec) - -
--ComplianceSnapshotterDeploymentPodSpec is the compliance snapshotter Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]ComplianceSnapshotterDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of compliance snapshotter init containers. -If specified, this overrides the specified compliance snapshotter Deployment init containers. -If omitted, the compliance snapshotter Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]ComplianceSnapshotterDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of compliance snapshotter containers. -If specified, this overrides the specified compliance snapshotter Deployment containers. -If omitted, the compliance snapshotter Deployment will use its default values for its containers. - - - |
-
ComplianceSnapshotterDeploymentPodTemplateSpec
-- -(Appears on: -ComplianceSnapshotterDeploymentSpec) - -
--ComplianceSnapshotterDeploymentPodTemplateSpec is the compliance snapshotter Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -ComplianceSnapshotterDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the compliance snapshotter Deployment’s PodSpec. - -- - |
-
ComplianceSnapshotterDeploymentSpec
-- -(Appears on: -ComplianceSnapshotterDeployment) - -
--ComplianceSnapshotterDeploymentSpec defines configuration for the compliance snapshotter Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -ComplianceSnapshotterDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the compliance snapshotter Deployment pod that will be created. - - - |
-
ComplianceSpec
-- -(Appears on: -Compliance) - -
--ComplianceSpec defines the desired state of Tigera compliance reporting capabilities. -
-| Field | -Description | -
|---|---|
-
-complianceControllerDeployment- - -ComplianceControllerDeployment - - - - |
-
-
-(Optional)
- -ComplianceControllerDeployment configures the Compliance Controller Deployment. - - - |
-
-
-complianceSnapshotterDeployment- - -ComplianceSnapshotterDeployment - - - - |
-
-
-(Optional)
- -ComplianceSnapshotterDeployment configures the Compliance Snapshotter Deployment. - - - |
-
-
-complianceBenchmarkerDaemonSet- - -ComplianceBenchmarkerDaemonSet - - - - |
-
-
-(Optional)
- -ComplianceBenchmarkerDaemonSet configures the Compliance Benchmarker DaemonSet. - - - |
-
-
-complianceServerDeployment- - -ComplianceServerDeployment - - - - |
-
-
-(Optional)
- -ComplianceServerDeployment configures the Compliance Server Deployment. - - - |
-
-
-complianceReporterPodTemplate- - -ComplianceReporterPodTemplate - - - - |
-
-
-(Optional)
- -ComplianceReporterPodTemplate configures the Compliance Reporter PodTemplate. - - - |
-
ComplianceStatus
-- -(Appears on: -Compliance) - -
--ComplianceStatus defines the observed state of Tigera compliance reporting capabilities. -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
ComponentName
-(string alias)
-- -(Appears on: -ComponentResource) - -
--ComponentName represents a single component. -
--One of: Node, Typha, KubeControllers -
-ComponentResource
-- -(Appears on: -InstallationSpec) - -
--Deprecated. Please use component resource config fields in Installation.Spec instead. -The ComponentResource struct associates a ResourceRequirements with a component by name -
-| Field | -Description | -
|---|---|
-
-componentName- - -ComponentName - - - - |
-
-
- -ComponentName is an enum which identifies the component - - - |
-
-
-resourceRequirements- - -Kubernetes core/v1.ResourceRequirements - - - - |
-
-
- -ResourceRequirements allows customization of limits and requests for compute resources such as cpu and memory. - - - |
-
ConditionStatus
-(string alias)
-- -(Appears on: -TigeraStatusCondition) - -
--ConditionStatus represents the status of a particular condition. A condition may be one of: True, False, Unknown. -
-ContainerIPForwardingType
-(string alias)
-- -(Appears on: -CalicoNetworkSpec) - -
--ContainerIPForwardingType specifies whether the CNI config for container ip forwarding is enabled. -
-DashboardsJob
-- -(Appears on: -TenantSpec) - -
--DashboardsJob is the configuration for the Dashboards job. -
-| Field | -Description | -
|---|---|
-
-spec- - -DashboardsJobSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the dashboards job. - -- - |
-
DashboardsJobContainer
-- -(Appears on: -DashboardsJobPodSpec) - -
--DashboardsJobContainer is the Dashboards job container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Dashboard Job container by name. -Supported values are: dashboards-installer - - - |
-
-
-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 Dashboard Job container’s resources. -If omitted, the Dashboard Job will use its default value for this container’s resources. - - - |
-
DashboardsJobPodSpec
-- -(Appears on: -DashboardsJobPodTemplateSpec) - -
--DashboardsJobPodSpec is the Dashboards job’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-containers- - -[]DashboardsJobContainer - - - - |
-
-
-(Optional)
- -Containers is a list of dashboards job containers. -If specified, this overrides the specified Dashboard job containers. -If omitted, the Dashboard job will use its default values for its containers. - - - |
-
DashboardsJobPodTemplateSpec
-- -(Appears on: -DashboardsJobSpec) - -
--DashboardsJobPodTemplateSpec is the Dashboards job’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -DashboardsJobPodSpec - - - - |
-
-
-(Optional)
- -Spec is the Dashboard job’s PodSpec. - -- - |
-
DashboardsJobSpec
-- -(Appears on: -DashboardsJob) - -
--DashboardsJobSpec defines configuration for the Dashboards job. -
-| Field | -Description | -
|---|---|
-
-template- - -DashboardsJobPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the Dashboards job pod that will be created. - - - |
-
DataType
-(string alias)
-- -(Appears on: -Index) - -
--DataType represent the type of data stored -
-DexDeployment
-- -(Appears on: -AuthenticationSpec) - -
--DexDeployment is the configuration for the Dex Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -DexDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the Dex Deployment. - -- - |
-
DexDeploymentContainer
-- -(Appears on: -DexDeploymentPodSpec) - -
--DexDeploymentContainer is a Dex Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Dex Deployment container by name. -Supported values are: tigera-dex - - - |
-
-
-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 Dex Deployment container’s resources. -If omitted, the Dex Deployment will use its default value for this container’s resources. - - - |
-
DexDeploymentInitContainer
-- -(Appears on: -DexDeploymentPodSpec) - -
--DexDeploymentInitContainer is a Dex Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Dex Deployment init container by name. -Supported values are: tigera-dex-tls-key-cert-provisioner - - - |
-
-
-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 Dex Deployment init container’s resources. -If omitted, the Dex Deployment will use its default value for this init container’s resources. - - - |
-
DexDeploymentPodSpec
-- -(Appears on: -DexDeploymentPodTemplateSpec) - -
--DexDeploymentPodSpec is the Dex Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]DexDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of Dex init containers. -If specified, this overrides the specified Dex Deployment init containers. -If omitted, the Dex Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]DexDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of Dex containers. -If specified, this overrides the specified Dex Deployment containers. -If omitted, the Dex Deployment will use its default values for its containers. - - - |
-
DexDeploymentPodTemplateSpec
-- -(Appears on: -DexDeploymentSpec) - -
--DexDeploymentPodTemplateSpec is the Dex Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -DexDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the Dex Deployment’s PodSpec. - -- - |
-
DexDeploymentSpec
-- -(Appears on: -DexDeployment) - -
--DexDeploymentSpec defines configuration for the Dex Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -DexDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the Dex Deployment pod that will be created. - - - |
-
ECKOperatorStatefulSet
-- -(Appears on: -LogStorageSpec) - -
--ECKOperatorStatefulSet is the configuration for the ECKOperator StatefulSet. -
-| Field | -Description | -
|---|---|
-
-spec- - -ECKOperatorStatefulSetSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the ECKOperator StatefulSet. - -- - |
-
ECKOperatorStatefulSetContainer
-- -(Appears on: -ECKOperatorStatefulSetPodSpec) - -
--ECKOperatorStatefulSetContainer is a ECKOperator StatefulSet container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the ECKOperator StatefulSet container by name. -Supported values are: manager - - - |
-
-
-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 ECKOperator StatefulSet container’s resources. -If omitted, the ECKOperator StatefulSet will use its default value for this container’s resources. - - - |
-
ECKOperatorStatefulSetInitContainer
-- -(Appears on: -ECKOperatorStatefulSetPodSpec) - -
--ECKOperatorStatefulSetInitContainer is a ECKOperator StatefulSet init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the ECKOperator StatefulSet init 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 ECKOperator StatefulSet init container’s resources. -If omitted, the ECKOperator StatefulSet will use its default value for this init container’s resources. - - - |
-
ECKOperatorStatefulSetPodSpec
-- -(Appears on: -ECKOperatorStatefulSetPodTemplateSpec) - -
--ECKOperatorStatefulSetPodSpec is the ECKOperator StatefulSet’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]ECKOperatorStatefulSetInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of ECKOperator StatefulSet init containers. -If specified, this overrides the specified ECKOperator StatefulSet init containers. -If omitted, the ECKOperator StatefulSet will use its default values for its init containers. - - - |
-
-
-containers- - -[]ECKOperatorStatefulSetContainer - - - - |
-
-
-(Optional)
- -Containers is a list of ECKOperator StatefulSet containers. -If specified, this overrides the specified ECKOperator StatefulSet containers. -If omitted, the ECKOperator StatefulSet will use its default values for its containers. - - - |
-
ECKOperatorStatefulSetPodTemplateSpec
-- -(Appears on: -ECKOperatorStatefulSetSpec) - -
--ECKOperatorStatefulSetPodTemplateSpec is the ECKOperator StatefulSet’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -ECKOperatorStatefulSetPodSpec - - - - |
-
-
-(Optional)
- -Spec is the ECKOperator StatefulSet’s PodSpec. - -- - |
-
ECKOperatorStatefulSetSpec
-- -(Appears on: -ECKOperatorStatefulSet) - -
--ECKOperatorStatefulSetSpec defines configuration for the ECKOperator StatefulSet. -
-| Field | -Description | -
|---|---|
-
-template- - -ECKOperatorStatefulSetPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the ECKOperator StatefulSet pod that will be created. - - - |
-
EGWDeploymentContainer
-- -(Appears on: -EgressGatewayDeploymentPodSpec) - -
--EGWDeploymentContainer is a Egress Gateway Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the EGW Deployment container by name. -Supported values are: calico-egw - - - |
-
-
-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 EGW Deployment container’s resources. -If omitted, the EGW Deployment will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
EGWDeploymentInitContainer
-- -(Appears on: -EgressGatewayDeploymentPodSpec) - -
--EGWDeploymentInitContainer is a Egress Gateway Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the EGW Deployment init container by name. -Supported values are: egress-gateway-init - - - |
-
-
-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 EGW Deployment init container’s resources. -If omitted, the EGW Deployment will use its default value for this init container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
EKSLogForwarderDeployment
-- -(Appears on: -LogCollectorSpec) - -
--EKSLogForwarderDeployment is the configuration for the EKSLogForwarder Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -EKSLogForwarderDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the EKSLogForwarder Deployment. - -- - |
-
EKSLogForwarderDeploymentContainer
-- -(Appears on: -EKSLogForwarderDeploymentPodSpec) - -
--EKSLogForwarderDeploymentContainer is a EKSLogForwarder Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the EKSLogForwarder Deployment container by name. -Supported values are: eks-log-forwarder - - - |
-
-
-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 EKSLogForwarder Deployment container’s resources. -If omitted, the EKSLogForwarder Deployment will use its default value for this container’s resources. - - - |
-
EKSLogForwarderDeploymentInitContainer
-- -(Appears on: -EKSLogForwarderDeploymentPodSpec) - -
--EKSLogForwarderDeploymentInitContainer is a EKSLogForwarder Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the EKSLogForwarder Deployment init container by name. -Supported values are: eks-log-forwarder-startup - - - |
-
-
-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 EKSLogForwarder Deployment init container’s resources. -If omitted, the EKSLogForwarder Deployment will use its default value for this init container’s resources. - - - |
-
EKSLogForwarderDeploymentPodSpec
-- -(Appears on: -EKSLogForwarderDeploymentPodTemplateSpec) - -
--EKSLogForwarderDeploymentPodSpec is the EKSLogForwarder Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]EKSLogForwarderDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of EKSLogForwarder init containers. -If specified, this overrides the specified EKSLogForwarder Deployment init containers. -If omitted, the EKSLogForwarder Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]EKSLogForwarderDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of EKSLogForwarder containers. -If specified, this overrides the specified EKSLogForwarder Deployment containers. -If omitted, the EKSLogForwarder Deployment will use its default values for its containers. - - - |
-
EKSLogForwarderDeploymentPodTemplateSpec
-- -(Appears on: -EKSLogForwarderDeploymentSpec) - -
--EKSLogForwarderDeploymentPodTemplateSpec is the EKSLogForwarder Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -EKSLogForwarderDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the EKSLogForwarder Deployment’s PodSpec. - -- - |
-
EKSLogForwarderDeploymentSpec
-- -(Appears on: -EKSLogForwarderDeployment) - -
--EKSLogForwarderDeploymentSpec defines configuration for the EKSLogForwarder Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -EKSLogForwarderDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the EKSLogForwarder Deployment pod that will be created. - - - |
-
EgressGatewayDeploymentPodSpec
-- -(Appears on: -EgressGatewayDeploymentPodTemplateSpec) - -
--EgressGatewayDeploymentPodSpec is the Egress Gateway Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]EGWDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of EGW init containers. -If specified, this overrides the specified EGW Deployment init containers. -If omitted, the EGW Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]EGWDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of EGW containers. -If specified, this overrides the specified EGW Deployment containers. -If omitted, the EGW Deployment will use its default values for its containers. - - - |
-
-
-affinity- - -Kubernetes core/v1.Affinity - - - - |
-
-
-(Optional)
- -Affinity is a group of affinity scheduling rules for the EGW pods. - - - |
-
-
-nodeSelector- -map[string]string - - - |
-
-
-(Optional)
- -NodeSelector gives more control over the nodes where the Egress Gateway pods will run on. - - - |
-
-
-terminationGracePeriodSeconds- -int64 - - - |
-
-
-(Optional)
- -TerminationGracePeriodSeconds defines the termination grace period of the Egress Gateway pods in seconds. - - - |
-
-
-topologySpreadConstraints- - -[]Kubernetes core/v1.TopologySpreadConstraint - - - - |
-
-
-(Optional)
- -TopologySpreadConstraints defines how the Egress Gateway pods should be spread across different AZs. - - - |
-
-
-tolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -Tolerations is the egress gateway pod’s tolerations. -If specified, this overrides any tolerations that may be set on the EGW Deployment. -If omitted, the EGW Deployment will use its default value for tolerations. - - - |
-
-
-priorityClassName- -string - - - |
-
-
-(Optional)
- -PriorityClassName allows to specify a PriorityClass resource to be used. - - - |
-
EgressGatewayDeploymentPodTemplateSpec
-- -(Appears on: -EgressGatewaySpec) - -
--EgressGatewayDeploymentPodTemplateSpec is the EGW Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-metadata- - -EgressGatewayMetadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. - - - |
-
-
-spec- - -EgressGatewayDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the EGW Deployment’s PodSpec. - -- - |
-
EgressGatewayFailureDetection
-- -(Appears on: -EgressGatewaySpec) - -
--EgressGatewayFailureDetection defines the fields the needed for determining Egress Gateway -readiness. -
-| Field | -Description | -
|---|---|
-
-healthTimeoutDataStoreSeconds- -int32 - - - |
-
-
-(Optional)
- -HealthTimeoutDataStoreSeconds defines how long Egress Gateway can fail to connect -to the datastore before reporting not ready. -This value must be greater than 0. -Default: 90 - - - |
-
-
-icmpProbe- - -ICMPProbe - - - - |
-
-
-(Optional)
- -ICMPProbe define outgoing ICMP probes that Egress Gateway will use to -verify its upstream connection. Egress Gateway will report not ready if all -fail. Timeout must be greater than interval. - - - |
-
-
-httpProbe- - -HTTPProbe - - - - |
-
-
-(Optional)
- -HTTPProbe define outgoing HTTP probes that Egress Gateway will use to -verify its upsteam connection. Egress Gateway will report not ready if all -fail. Timeout must be greater than interval. - - - |
-
EgressGatewayIPPool
-- -(Appears on: -EgressGatewaySpec) - -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
-(Optional)
- -Name is the name of the IPPool that the Egress Gateways can use. - - - |
-
-
-cidr- -string - - - |
-
-
-(Optional)
- -CIDR is the IPPool CIDR that the Egress Gateways can use. - - - |
-
EgressGatewayMetadata
-- -(Appears on: -EgressGatewayDeploymentPodTemplateSpec) - -
--EgressGatewayMetadata contains the standard Kubernetes labels and annotations fields. -
-| Field | -Description | -
|---|---|
-
-labels- -map[string]string - - - |
-
-
-(Optional)
- -Labels is a map of string keys and values that may match replica set and -service selectors. Each of these key/value pairs are added to the -object’s labels provided the key does not already exist in the object’s labels. -If not specified will default to projectcalico.org/egw:[name], where [name] is -the name of the Egress Gateway resource. - - - |
-
-
-annotations- -map[string]string - - - |
-
-
-(Optional)
- -Annotations is a map of arbitrary non-identifying metadata. Each of these -key/value pairs are added to the object’s annotations provided the key does not -already exist in the object’s annotations. - - - |
-
EgressGatewaySpec
-- -(Appears on: -EgressGateway) - -
--EgressGatewaySpec defines the desired state of EgressGateway -
-| Field | -Description | -
|---|---|
-
-replicas- -int32 - - - |
-
-
-(Optional)
- -Replicas defines how many instances of the Egress Gateway pod will run. - - - |
-
-
-ipPools- - -[]EgressGatewayIPPool - - - - |
-
-
- -IPPools defines the IP Pools that the Egress Gateway pods should be using. -Either name or CIDR must be specified. -IPPools must match existing IPPools. - - - |
-
-
-externalNetworks- -[]string - - - |
-
-
-(Optional)
- -ExternalNetworks defines the external network names this Egress Gateway is -associated with. -ExternalNetworks must match existing external networks. - - - |
-
-
-logSeverity- - -LogLevel - - - - |
-
-
-(Optional)
- -LogSeverity defines the logging level of the Egress Gateway. -Default: Info - - - |
-
-
-template- - -EgressGatewayDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the EGW Deployment pod that will be created. - - - |
-
-
-egressGatewayFailureDetection- - -EgressGatewayFailureDetection - - - - |
-
-
-(Optional)
- -EgressGatewayFailureDetection is used to configure how Egress Gateway -determines readiness. If both ICMP, HTTP probes are defined, one ICMP probe and one -HTTP probe should succeed for Egress Gateways to become ready. -Otherwise one of ICMP or HTTP probe should succeed for Egress gateways to become -ready if configured. - - - |
-
-
-aws- - -AWSEgressGateway - - - - |
-
-
-(Optional)
- -AWS defines the additional configuration options for Egress Gateways on AWS. - - - |
-
EgressGatewayStatus
-- -(Appears on: -EgressGateway) - -
--EgressGatewayStatus defines the observed state of EgressGateway -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
EksCloudwatchLogsSpec
-- -(Appears on: -AdditionalLogSourceSpec) - -
--EksConfigSpec defines configuration for fetching EKS audit logs. -
-| Field | -Description | -
|---|---|
-
-region- -string - - - |
-
-
- -AWS Region EKS cluster is hosted in. - - - |
-
-
-groupName- -string - - - |
-
-
- -Cloudwatch log-group name containing EKS audit logs. - - - |
-
-
-streamPrefix- -string - - - |
-
-
-(Optional)
- -Prefix of Cloudwatch log stream containing EKS audit logs in the log-group. -Default: kube-apiserver-audit- - - - |
-
-
-fetchInterval- -int32 - - - |
-
-
-(Optional)
- -Cloudwatch audit logs fetching interval in seconds. -Default: 60 - - - |
-
ElasticsearchMetricsDeployment
-- -(Appears on: -LogStorageSpec) - -
--ElasticsearchMetricsDeployment is the configuration for the tigera-elasticsearch-metric Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -ElasticsearchMetricsDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the ElasticsearchMetrics Deployment. - -- - |
-
ElasticsearchMetricsDeploymentContainer
-- -(Appears on: -ElasticsearchMetricsDeploymentPodSpec) - -
--ElasticsearchMetricsDeploymentContainer is a ElasticsearchMetricsDeployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the ElasticsearchMetricsDeployment container by name. -Supported values are: tigera-elasticsearch-metrics - - - |
-
-
-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 ElasticsearchMetricsDeployment container’s resources. -If omitted, the ElasticsearchMetrics Deployment will use its default value for this container’s resources. - - - |
-
ElasticsearchMetricsDeploymentInitContainer
-- -(Appears on: -ElasticsearchMetricsDeploymentPodSpec) - -
--ElasticsearchMetricsDeploymentInitContainer is a ElasticsearchMetricsDeployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the ElasticsearchMetricsDeployment init container by name. -Supported values are: tigera-ee-elasticsearch-metrics-tls-key-cert-provisioner - - - |
-
-
-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 ElasticsearchMetricsDeployment init container’s resources. -If omitted, the ElasticsearchMetrics Deployment will use its default value for this init container’s resources. - - - |
-
ElasticsearchMetricsDeploymentPodSpec
-- -(Appears on: -ElasticsearchMetricsDeploymentPodTemplateSpec) - -
--ElasticsearchMetricsDeploymentPodSpec is the tElasticsearchMetricsDeployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]ElasticsearchMetricsDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of ElasticsearchMetricsDeployment init containers. -If specified, this overrides the specified ElasticsearchMetricsDeployment init containers. -If omitted, the ElasticsearchMetrics Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]ElasticsearchMetricsDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of ElasticsearchMetricsDeployment containers. -If specified, this overrides the specified ElasticsearchMetricsDeployment containers. -If omitted, the ElasticsearchMetrics Deployment will use its default values for its containers. - - - |
-
ElasticsearchMetricsDeploymentPodTemplateSpec
-- -(Appears on: -ElasticsearchMetricsDeploymentSpec) - -
--ElasticsearchMetricsDeploymentPodTemplateSpec is the ElasticsearchMetricsDeployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -ElasticsearchMetricsDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the ElasticsearchMetrics Deployment’s PodSpec. - -- - |
-
ElasticsearchMetricsDeploymentSpec
-- -(Appears on: -ElasticsearchMetricsDeployment) - -
--ElasticsearchMetricsDeploymentSpec defines configuration for the ElasticsearchMetricsDeployment Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -ElasticsearchMetricsDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the ElasticsearchMetrics Deployment pod that will be created. - - - |
-
EmailVerificationType
-(string alias)
-- -(Appears on: -AuthenticationOIDC) - -
-EncapsulationType
-(string alias)
-- -(Appears on: -IPPool) - -
--EncapsulationType is the type of encapsulation to use on an IP pool. -
--One of: IPIP, VXLAN, IPIPCrossSubnet, VXLANCrossSubnet, None -
-EncryptionOption
-(string alias)
-- -(Appears on: -SyslogStoreSpec) - -
--EncryptionOption specifies the traffic encryption mode when connecting to a Syslog server. -
--One of: None, TLS -
-Endpoint
-- -(Appears on: -ServiceMonitor) - -
--Endpoint contains a subset of relevant fields from the Prometheus Endpoint struct. -
-| Field | -Description | -
|---|---|
-
-params- -map[string][]string - - - |
-
-
- -Optional HTTP URL parameters -Default: scrape all metrics. - - - |
-
-
-bearerTokenSecret- - -Kubernetes core/v1.SecretKeySelector - - - - |
-
-
- -Secret to mount to read bearer token for scraping targets. -Recommended: when unset, the operator will create a Secret, a ClusterRole and a ClusterRoleBinding. - - - |
-
-
-interval- -github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring/v1.Duration - - - |
-
-
- -Interval at which metrics should be scraped. -If not specified Prometheus’ global scrape interval is used. - - - |
-
-
-scrapeTimeout- -github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring/v1.Duration - - - |
-
-
-
-Timeout after which the scrape is ended.
-If not specified, the Prometheus global scrape timeout is used unless it is less than |
-
-
-honorLabels- -bool - - - |
-
-
- -HonorLabels chooses the metric’s labels on collisions with target labels. - - - |
-
-
-honorTimestamps- -bool - - - |
-
-
- -HonorTimestamps controls whether Prometheus respects the timestamps present in scraped data. - - - |
-
-
-metricRelabelings- -[]*github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring/v1.RelabelConfig - - - |
-
-
- -MetricRelabelConfigs to apply to samples before ingestion. - - - |
-
-
-relabelings- -[]*github.com/prometheus-operator/prometheus-operator/pkg/apis/monitoring/v1.RelabelConfig - - - |
-
-
-
-RelabelConfigs to apply to samples before scraping.
-Prometheus Operator automatically adds relabelings for a few standard Kubernetes fields.
-The original scrape job’s name is available via the |
-
EnvoySettings
-- -(Appears on: -ApplicationLayerSpec) - -
-| Field | -Description | -
|---|---|
-
-xffNumTrustedHops- -int32 - - - |
-
-
-(Optional)
- -The number of additional ingress proxy hops from the right side of the -x-forwarded-for HTTP header to trust when determining the origin client’s -IP address. 0 is permitted, but >=1 is the typical setting. - - - |
-
-
-useRemoteAddress- -bool - - - |
-
-
-(Optional)
- -If set to true, the Envoy connection manager will use the real remote address -of the client connection when determining internal versus external origin and -manipulating various headers. - - - |
-
ExternalPrometheus
-- -(Appears on: -MonitorSpec) - -
-| Field | -Description | -
|---|---|
-
-serviceMonitor- - -ServiceMonitor - - - - |
-
-
-(Optional)
- -ServiceMonitor when specified, the operator will create a ServiceMonitor object in the namespace. It is recommended -that you configure labels if you want your prometheus instance to pick up the configuration automatically. -The operator will configure 1 endpoint by default: -- Params to scrape all metrics available in Calico Enterprise. -- BearerTokenSecret (If not overridden, the operator will also create corresponding RBAC that allows authz to the metrics.) -- TLSConfig, containing the caFile and serverName. - - - |
-
-
-namespace- -string - - - |
-
-
- -Namespace is the namespace where the operator will create resources for your Prometheus instance. The namespace -must be created before the operator will create Prometheus resources. - - - |
-
FIPSMode
-(string alias)
-- -(Appears on: -InstallationSpec) - -
-FluentdDaemonSet
-- -(Appears on: -LogCollectorSpec) - -
--FluentdDaemonSet is the configuration for the Fluentd DaemonSet. -
-| Field | -Description | -
|---|---|
-
-spec- - -FluentdDaemonSetSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the Fluentd DaemonSet. - -- - |
-
FluentdDaemonSetContainer
-- -(Appears on: -FluentdDaemonSetPodSpec) - -
--FluentdDaemonSetContainer is a Fluentd DaemonSet container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Fluentd DaemonSet container by name. -Supported values are: fluentd - - - |
-
-
-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 Fluentd DaemonSet container’s resources. -If omitted, the Fluentd DaemonSet will use its default value for this container’s resources. - - - |
-
FluentdDaemonSetInitContainer
-- -(Appears on: -FluentdDaemonSetPodSpec) - -
--FluentdDaemonSetInitContainer is a Fluentd DaemonSet init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Fluentd DaemonSet init container by name. -Supported values are: tigera-fluentd-prometheus-tls-key-cert-provisioner - - - |
-
-
-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 Fluentd DaemonSet init container’s resources. -If omitted, the Fluentd DaemonSet will use its default value for this init container’s resources. - - - |
-
FluentdDaemonSetPodSpec
-- -(Appears on: -FluentdDaemonSetPodTemplateSpec) - -
--FluentdDaemonSetPodSpec is the Fluentd DaemonSet’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]FluentdDaemonSetInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of Fluentd DaemonSet init containers. -If specified, this overrides the specified Fluentd DaemonSet init containers. -If omitted, the Fluentd DaemonSet will use its default values for its init containers. - - - |
-
-
-containers- - -[]FluentdDaemonSetContainer - - - - |
-
-
-(Optional)
- -Containers is a list of Fluentd DaemonSet containers. -If specified, this overrides the specified Fluentd DaemonSet containers. -If omitted, the Fluentd DaemonSet will use its default values for its containers. - - - |
-
FluentdDaemonSetPodTemplateSpec
-- -(Appears on: -FluentdDaemonSetSpec) - -
--FluentdDaemonSetPodTemplateSpec is the Fluentd DaemonSet’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -FluentdDaemonSetPodSpec - - - - |
-
-
-(Optional)
- -Spec is the Fluentd DaemonSet’s PodSpec. - -- - |
-
FluentdDaemonSetSpec
-- -(Appears on: -FluentdDaemonSet) - -
--FluentdDaemonSetSpec defines configuration for the Fluentd DaemonSet. -
-| Field | -Description | -
|---|---|
-
-template- - -FluentdDaemonSetPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the Fluentd DaemonSet pod that will be created. - - - |
-
GroupSearch
-- -(Appears on: -AuthenticationLDAP) - -
--Group search configuration to find the groups that a user is in. -
-| Field | -Description | -
|---|---|
-
-baseDN- -string - - - |
-
-
- -BaseDN to start the search from. For example “cn=groups,dc=example,dc=com” - - - |
-
-
-filter- -string - - - |
-
-
-(Optional)
- -Optional filter to apply when searching the directory. -For example “(objectClass=posixGroup)” - - - |
-
-
-nameAttribute- -string - - - |
-
-
- -The attribute of the group that represents its name. This attribute can be used to apply RBAC to a user group. - - - |
-
-
-userMatchers- - -[]UserMatch - - - - |
-
-
- -Following list contains field pairs that are used to match a user to a group. It adds an additional -requirement to the filter that an attribute in the group must match the user’s -attribute value. - - - |
-
GuardianDeployment
-- -(Appears on: -ManagementClusterConnectionSpec) - -
--GuardianDeployment is the configuration for the guardian Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -GuardianDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the guardian Deployment. - -- - |
-
GuardianDeploymentContainer
-- -(Appears on: -GuardianDeploymentPodSpec) - -
--GuardianDeploymentContainer is a guardian Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the guardian Deployment container by name. -Supported values are: tigera-guardian - - - |
-
-
-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 guardian Deployment container’s resources. -If omitted, the guardian Deployment will use its default value for this container’s resources. - - - |
-
GuardianDeploymentInitContainer
-- -(Appears on: -GuardianDeploymentPodSpec) - -
--GuardianDeploymentInitContainer is a guardian Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the guardian Deployment init 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 guardian Deployment init container’s resources. -If omitted, the guardian Deployment will use its default value for this init container’s resources. - - - |
-
GuardianDeploymentPodSpec
-- -(Appears on: -GuardianDeploymentPodTemplateSpec) - -
--GuardianDeploymentPodSpec is the guardian Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]GuardianDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of guardian init containers. -If specified, this overrides the specified guardian Deployment init containers. -If omitted, the guardian Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]GuardianDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of guardian containers. -If specified, this overrides the specified guardian Deployment containers. -If omitted, the guardian Deployment will use its default values for its containers. - - - |
-
GuardianDeploymentPodTemplateSpec
-- -(Appears on: -GuardianDeploymentSpec) - -
--GuardianDeploymentPodTemplateSpec is the guardian Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -GuardianDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the guardian Deployment’s PodSpec. - -- - |
-
GuardianDeploymentSpec
-- -(Appears on: -GuardianDeployment) - -
--GuardianDeploymentSpec defines configuration for the guardian Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -GuardianDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the guardian Deployment pod that will be created. - - - |
-
HTTPProbe
-- -(Appears on: -EgressGatewayFailureDetection) - -
--HTTPProbe defines the HTTP probe configuration for Egress Gateway. -
-| Field | -Description | -
|---|---|
-
-urls- -[]string - - - |
-
-
- -URLs define the list of HTTP probe URLs. Egress Gateway will probe each URL -periodically.If all probes fail, Egress Gateway will report non-ready. - - - |
-
-
-intervalSeconds- -int32 - - - |
-
-
-(Optional)
- -IntervalSeconds defines the interval of HTTP probes. Used when URLs is non-empty. -Default: 10 - - - |
-
-
-timeoutSeconds- -int32 - - - |
-
-
-(Optional)
- -TimeoutSeconds defines the timeout value of HTTP probes. Used when URLs is non-empty. -Default: 30 - - - |
-
HostPortsType
-(string alias)
-- -(Appears on: -CalicoNetworkSpec) - -
--HostPortsType specifies host port support. -
--One of: Enabled, Disabled -
-ICMPProbe
-- -(Appears on: -EgressGatewayFailureDetection) - -
--ICMPProbe defines the ICMP probe configuration for Egress Gateway. -
-| Field | -Description | -
|---|---|
-
-ips- -[]string - - - |
-
-
- -IPs define the list of ICMP probe IPs. Egress Gateway will probe each IP -periodically. If all probes fail, Egress Gateway will report non-ready. - - - |
-
-
-intervalSeconds- -int32 - - - |
-
-
-(Optional)
- -IntervalSeconds defines the interval of ICMP probes. Used when IPs is non-empty. -Default: 5 - - - |
-
-
-timeoutSeconds- -int32 - - - |
-
-
-(Optional)
- -TimeoutSeconds defines the timeout value of ICMP probes. Used when IPs is non-empty. -Default: 15 - - - |
-
IPAMPluginType
-(string alias)
-- -(Appears on: -IPAMSpec) - -
-IPAMSpec
-- -(Appears on: -CNISpec) - -
--IPAMSpec contains configuration for pod IP address management. -
-| Field | -Description | -
|---|---|
-
-type- - -IPAMPluginType - - - - |
-
-
- -Specifies the IPAM plugin that will be used in the Calico or Calico Enterprise installation. -* For CNI Plugin Calico, this field defaults to Calico. -* For CNI Plugin GKE, this field defaults to HostLocal. -* For CNI Plugin AzureVNET, this field defaults to AzureVNET. -* For CNI Plugin AmazonVPC, this field defaults to AmazonVPC. - --The IPAM plugin is installed and configured only if the CNI plugin is set to Calico, -for all other values of the CNI plugin the plugin binaries and CNI config is a dependency -that is expected to be installed separately. - --Default: Calico - - - |
-
IPPool
-- -(Appears on: -CalicoNetworkSpec) - -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is the name of the IP pool. If omitted, this will be generated. - - - |
-
-
-cidr- -string - - - |
-
-
- -CIDR contains the address range for the IP Pool in classless inter-domain routing format. - - - |
-
-
-encapsulation- - -EncapsulationType - - - - |
-
-
-(Optional)
- -Encapsulation specifies the encapsulation type that will be used with -the IP Pool. -Default: IPIP - - - |
-
-
-natOutgoing- - -NATOutgoingType - - - - |
-
-
-(Optional)
- -NATOutgoing specifies if NAT will be enabled or disabled for outgoing traffic. -Default: Enabled - - - |
-
-
-nodeSelector- -string - - - |
-
-
-(Optional)
- -NodeSelector specifies the node selector that will be set for the IP Pool. -Default: ‘all()’ - - - |
-
-
-blockSize- -int32 - - - |
-
-
-(Optional)
- -BlockSize specifies the CIDR prefex length to use when allocating per-node IP blocks from -the main IP pool CIDR. -Default: 26 (IPv4), 122 (IPv6) - - - |
-
-
-disableBGPExport- -bool - - - |
-
-
-(Optional)
- -DisableBGPExport specifies whether routes from this IP pool’s CIDR are exported over BGP. -Default: false - - - |
-
-
-allowedUses- - -[]IPPoolAllowedUse - - - - |
-
-
- -AllowedUse controls what the IP pool will be used for. If not specified or empty, defaults to -[“Tunnel”, “Workload”] for back-compatibility - - - |
-
IPPoolAllowedUse
-(string alias)
-- -(Appears on: -IPPool) - -
-Image
-- -(Appears on: -ImageSetSpec) - -
-| Field | -Description | -
|---|---|
-
-image- -string - - - |
-
-
-
-Image is an image that the operator deploys and instead of using the built in tag
-the operator will use the Digest for the image identifier.
-The value should be the image name without registry or tag or digest.
-For the image |
-
-
-digest- -string - - - |
-
-
-
-Digest is the image identifier that will be used for the Image.
-The field should not include a leading |
-
ImageSetSpec
-- -(Appears on: -ImageSet) - -
--ImageSetSpec defines the desired state of ImageSet. -
-| Field | -Description | -
|---|---|
-
-images- - -[]Image - - - - |
-
-
- -Images is the list of images to use digests. All images that the operator will deploy -must be specified. - - - |
-
Index
-- -(Appears on: -TenantSpec) - -
--Index defines how to store a tenant’s data -
-| Field | -Description | -
|---|---|
-
-baseIndexName- -string - - - |
-
-
- -BaseIndexName defines the name of the index -that will be used to store data (this name -excludes the numerical identifier suffix) - - - |
-
-
-dataType- - -DataType - - - - |
-
-
- -DataType represents the type of data stored in the defined index - - - |
-
Indices
-- -(Appears on: -LogStorageSpec) - -
--Indices defines the configuration for the indices in an Elasticsearch cluster. -
-| Field | -Description | -
|---|---|
-
-replicas- -int32 - - - |
-
-
-(Optional)
- -Replicas defines how many replicas each index will have. See https://www.elastic.co/guide/en/elasticsearch/reference/current/scalability.html - - - |
-
InstallationSpec
-- -(Appears on: -Installation, -InstallationStatus) - -
--InstallationSpec defines configuration for a Calico or Calico Enterprise installation. -
-| Field | -Description | -
|---|---|
-
-variant- - -ProductVariant - - - - |
-
-
-(Optional)
- -Variant is the product to install - one of Calico or TigeraSecureEnterprise -Default: Calico - - - |
-
-
-registry- -string - - - |
-
-
-(Optional)
-
-Registry is the default Docker registry used for component Docker images.
-If specified then the given value must end with a slash character (
-Image format:
-
-This option allows configuring the |
-
-
-imagePath- -string - - - |
-
-
-(Optional)
- -ImagePath allows for the path part of an image to be specified. If specified -then the specified value will be used as the image path for each image. If not specified -or empty, the default for each image will be used. -A special case value, UseDefault, is supported to explicitly specify the default -image path will be used for each image. - -
-Image format:
-
-This option allows configuring the |
-
-
-imagePrefix- -string - - - |
-
-
-(Optional)
- -ImagePrefix allows for the prefix part of an image to be specified. If specified -then the given value will be used as a prefix on each image. If not specified -or empty, no prefix will be used. -A special case value, UseDefault, is supported to explicitly specify the default -image prefix will be used for each image. - -
-Image format:
-
-This option allows configuring the |
-
-
-imagePullSecrets- - -[]Kubernetes core/v1.LocalObjectReference - - - - |
-
-
-(Optional)
- -ImagePullSecrets is an array of references to container registry pull secrets to use. These are -applied to all images to be pulled. - - - |
-
-
-kubernetesProvider- - -Provider - - - - |
-
-
-(Optional)
- -KubernetesProvider specifies a particular provider of the Kubernetes platform and enables provider-specific configuration. -If the specified value is empty, the Operator will attempt to automatically determine the current provider. -If the specified value is not empty, the Operator will still attempt auto-detection, but -will additionally compare the auto-detected value to the specified value to confirm they match. - - - |
-
-
-cni- - -CNISpec - - - - |
-
-
-(Optional)
- -CNI specifies the CNI that will be used by this installation. - - - |
-
-
-calicoNetwork- - -CalicoNetworkSpec - - - - |
-
-
-(Optional)
- -CalicoNetwork specifies networking configuration options for Calico. - - - |
-
-
-typhaAffinity- - -TyphaAffinity - - - - |
-
-
-(Optional)
- -Deprecated. Please use Installation.Spec.TyphaDeployment instead. -TyphaAffinity allows configuration of node affinity characteristics for Typha pods. - - - |
-
-
-controlPlaneNodeSelector- -map[string]string - - - |
-
-
-(Optional)
- -ControlPlaneNodeSelector is used to select control plane nodes on which to run Calico -components. This is globally applied to all resources created by the operator excluding daemonsets. - - - |
-
-
-controlPlaneTolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -ControlPlaneTolerations specify tolerations which are then globally applied to all resources -created by the operator. - - - |
-
-
-controlPlaneReplicas- -int32 - - - |
-
-
-(Optional)
- -ControlPlaneReplicas defines how many replicas of the control plane core components will be deployed. -This field applies to all control plane components that support High Availability. Defaults to 2. - - - |
-
-
-nodeMetricsPort- -int32 - - - |
-
-
-(Optional)
- -NodeMetricsPort specifies which port calico/node serves prometheus metrics on. By default, metrics are not enabled. -If specified, this overrides any FelixConfiguration resources which may exist. If omitted, then -prometheus metrics may still be configured through FelixConfiguration. - - - |
-
-
-typhaMetricsPort- -int32 - - - |
-
-
-(Optional)
- -TyphaMetricsPort specifies which port calico/typha serves prometheus metrics on. By default, metrics are not enabled. - - - |
-
-
-flexVolumePath- -string - - - |
-
-
-(Optional)
- -FlexVolumePath optionally specifies a custom path for FlexVolume. If not specified, FlexVolume will be -enabled by default. If set to ‘None’, FlexVolume will be disabled. The default is based on the -kubernetesProvider. - - - |
-
-
-kubeletVolumePluginPath- -string - - - |
-
-
-(Optional)
- -KubeletVolumePluginPath optionally specifies enablement of Calico CSI plugin. If not specified, -CSI will be enabled by default. If set to ‘None’, CSI will be disabled. -Default: /var/lib/kubelet - - - |
-
-
-nodeUpdateStrategy- - -Kubernetes apps/v1.DaemonSetUpdateStrategy - - - - |
-
-
-(Optional)
- -NodeUpdateStrategy can be used to customize the desired update strategy, such as the MaxUnavailable -field. - - - |
-
-
-componentResources- - -[]ComponentResource - - - - |
-
-
-(Optional)
- -Deprecated. Please use CalicoNodeDaemonSet, TyphaDeployment, and KubeControllersDeployment. -ComponentResources can be used to customize the resource requirements for each component. -Node, Typha, and KubeControllers are supported for installations. - - - |
-
-
-certificateManagement- - -CertificateManagement - - - - |
-
-
-(Optional)
- -CertificateManagement configures pods to submit a CertificateSigningRequest to the certificates.k8s.io/v1beta1 API in order -to obtain TLS certificates. This feature requires that you bring your own CSR signing and approval process, otherwise -pods will be stuck during initialization. - - - |
-
-
-nonPrivileged- - -NonPrivilegedType - - - - |
-
-
-(Optional)
- -NonPrivileged configures Calico to be run in non-privileged containers as non-root users where possible. - - - |
-
-
-calicoNodeDaemonSet- - -CalicoNodeDaemonSet - - - - |
-
-
- -CalicoNodeDaemonSet configures the calico-node DaemonSet. If used in -conjunction with the deprecated ComponentResources, then these overrides take precedence. - - - |
-
-
-csiNodeDriverDaemonSet- - -CSINodeDriverDaemonSet - - - - |
-
-
- -CSINodeDriverDaemonSet configures the csi-node-driver DaemonSet. - - - |
-
-
-calicoKubeControllersDeployment- - -CalicoKubeControllersDeployment - - - - |
-
-
- -CalicoKubeControllersDeployment configures the calico-kube-controllers Deployment. If used in -conjunction with the deprecated ComponentResources, then these overrides take precedence. - - - |
-
-
-typhaDeployment- - -TyphaDeployment - - - - |
-
-
- -TyphaDeployment configures the typha Deployment. If used in conjunction with the deprecated -ComponentResources or TyphaAffinity, then these overrides take precedence. - - - |
-
-
-calicoWindowsUpgradeDaemonSet- - -CalicoWindowsUpgradeDaemonSet - - - - |
-
-
- -Deprecated. The CalicoWindowsUpgradeDaemonSet is deprecated and will be removed from the API in the future. -CalicoWindowsUpgradeDaemonSet configures the calico-windows-upgrade DaemonSet. - - - |
-
-
-calicoNodeWindowsDaemonSet- - -CalicoNodeWindowsDaemonSet - - - - |
-
-
- -CalicoNodeWindowsDaemonSet configures the calico-node-windows DaemonSet. - - - |
-
-
-fipsMode- - -FIPSMode - - - - |
-
-
-(Optional)
- -FIPSMode uses images and features only that are using FIPS 140-2 validated cryptographic modules and standards. -Default: Disabled - - - |
-
-
-logging- - -Logging - - - - |
-
-
-(Optional)
- -Logging Configuration for Components - - - |
-
-
-windowsNodes- - -WindowsNodeSpec - - - - |
-
-
-(Optional)
- -Windows Configuration - - - |
-
-
-serviceCIDRs- -[]string - - - |
-
-
-(Optional)
- -Kubernetes Service CIDRs. Specifying this is required when using Calico for Windows. - - - |
-
InstallationStatus
-- -(Appears on: -Installation) - -
--InstallationStatus defines the observed state of the Calico or Calico Enterprise installation. -
-| Field | -Description | -
|---|---|
-
-variant- - -ProductVariant - - - - |
-
-
- -Variant is the most recently observed installed variant - one of Calico or TigeraSecureEnterprise - - - |
-
-
-mtu- -int32 - - - |
-
-
- -MTU is the most recently observed value for pod network MTU. This may be an explicitly -configured value, or based on Calico’s native auto-detetion. - - - |
-
-
-imageSet- -string - - - |
-
-
-(Optional)
- -ImageSet is the name of the ImageSet being used, if there is an ImageSet -that is being used. If an ImageSet is not being used then this will not be set. - - - |
-
-
-computed- - -InstallationSpec - - - - |
-
-
-(Optional)
- -Computed is the final installation including overlaid resources. - - - |
-
-
-calicoVersion- -string - - - |
-
-
- -CalicoVersion shows the current running version of calico. -CalicoVersion along with Variant is needed to know the exact -version deployed. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
IntrusionDetectionComponentName
-(string alias)
-- -(Appears on: -IntrusionDetectionComponentResource) - -
-IntrusionDetectionComponentResource
-- -(Appears on: -IntrusionDetectionSpec) - -
--The ComponentResource struct associates a ResourceRequirements with a component by name -
-| Field | -Description | -
|---|---|
-
-componentName- - -IntrusionDetectionComponentName - - - - |
-
-
- -ComponentName is an enum which identifies the component - - - |
-
-
-resourceRequirements- - -Kubernetes core/v1.ResourceRequirements - - - - |
-
-
- -ResourceRequirements allows customization of limits and requests for compute resources such as cpu and memory. - - - |
-
IntrusionDetectionControllerDeployment
-- -(Appears on: -IntrusionDetectionSpec) - -
--IntrusionDetectionControllerDeployment is the configuration for the IntrusionDetectionController Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -IntrusionDetectionControllerDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the IntrusionDetectionController Deployment. - -- - |
-
IntrusionDetectionControllerDeploymentContainer
-- -(Appears on: -IntrusionDetectionControllerDeploymentPodSpec) - -
--IntrusionDetectionControllerDeploymentContainer is a IntrusionDetectionController Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the IntrusionDetectionController Deployment container by name. -Supported values are: controller, webhooks-processor - - - |
-
-
-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 IntrusionDetectionController Deployment container’s resources. -If omitted, the IntrusionDetection Deployment will use its default value for this container’s resources. - - - |
-
IntrusionDetectionControllerDeploymentInitContainer
-- -(Appears on: -IntrusionDetectionControllerDeploymentPodSpec) - -
--IntrusionDetectionControllerDeploymentInitContainer is a IntrusionDetectionController Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the IntrusionDetectionController Deployment init container by name. -Supported values are: intrusion-detection-tls-key-cert-provisioner - - - |
-
-
-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 IntrusionDetectionController Deployment init container’s resources. -If omitted, the IntrusionDetectionController Deployment will use its default value for this init container’s resources. - - - |
-
IntrusionDetectionControllerDeploymentPodSpec
-- -(Appears on: -IntrusionDetectionControllerDeploymentPodTemplateSpec) - -
--IntrusionDetectionControllerDeploymentPodSpec is the IntrusionDetectionController Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]IntrusionDetectionControllerDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of IntrusionDetectionController init containers. -If specified, this overrides the specified IntrusionDetectionController Deployment init containers. -If omitted, the IntrusionDetectionController Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]IntrusionDetectionControllerDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of IntrusionDetectionController containers. -If specified, this overrides the specified IntrusionDetectionController Deployment containers. -If omitted, the IntrusionDetectionController Deployment will use its default values for its containers. - - - |
-
IntrusionDetectionControllerDeploymentPodTemplateSpec
-- -(Appears on: -IntrusionDetectionControllerDeploymentSpec) - -
--IntrusionDetectionControllerDeploymentPodTemplateSpec is the IntrusionDetectionController Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -IntrusionDetectionControllerDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the IntrusionDetectionController Deployment’s PodSpec. - -- - |
-
IntrusionDetectionControllerDeploymentSpec
-- -(Appears on: -IntrusionDetectionControllerDeployment) - -
--IntrusionDetectionControllerDeploymentSpec defines configuration for the IntrusionDetectionController Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -IntrusionDetectionControllerDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the IntrusionDetectionController Deployment pod that will be created. - - - |
-
IntrusionDetectionSpec
-- -(Appears on: -IntrusionDetection) - -
--IntrusionDetectionSpec defines the desired state of Tigera intrusion detection capabilities. -
-| Field | -Description | -
|---|---|
-
-componentResources- - -[]IntrusionDetectionComponentResource - - - - |
-
-
-(Optional)
- -ComponentResources can be used to customize the resource requirements for each component. -Only DeepPacketInspection is supported for this spec. - - - |
-
-
-anomalyDetection- - -AnomalyDetectionSpec - - - - |
-
-
-(Optional)
- -AnomalyDetection is now deprecated, and configuring it has no effect. - - - |
-
-
-intrusionDetectionControllerDeployment- - -IntrusionDetectionControllerDeployment - - - - |
-
-
-(Optional)
- -IntrusionDetectionControllerDeployment configures the IntrusionDetection Controller Deployment. - - - |
-
IntrusionDetectionStatus
-- -(Appears on: -IntrusionDetection) - -
--IntrusionDetectionStatus defines the observed state of Tigera intrusion detection capabilities. -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
Kibana
-- -(Appears on: -LogStorageSpec) - -
--Kibana is the configuration for the Kibana. -
-| Field | -Description | -
|---|---|
-
-spec- - -KibanaSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the Kibana. - -- - |
-
KibanaContainer
-- -(Appears on: -KibanaPodSpec) - -
--KibanaContainer is a Kibana container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Kibana Deployment container by name. -Supported values are: kibana - - - |
-
-
-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 Kibana container’s resources. -If omitted, the Kibana will use its default value for this container’s resources. - - - |
-
KibanaInitContainer
-- -(Appears on: -KibanaPodSpec) - -
--KibanaInitContainer is a Kibana init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Kibana init container by name. -Supported values are: key-cert-provisioner - - - |
-
-
-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 Kibana Deployment init container’s resources. -If omitted, the Kibana Deployment will use its default value for this init container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
KibanaPodSpec
-- -(Appears on: -KibanaPodTemplateSpec) - -
--KibanaPodSpec is the Kibana Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]KibanaInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of Kibana init containers. -If specified, this overrides the specified Kibana Deployment init containers. -If omitted, the Kibana Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]KibanaContainer - - - - |
-
-
-(Optional)
- -Containers is a list of Kibana containers. -If specified, this overrides the specified Kibana Deployment containers. -If omitted, the Kibana Deployment will use its default values for its containers. - - - |
-
KibanaPodTemplateSpec
-- -(Appears on: -KibanaSpec) - -
--KibanaPodTemplateSpec is the Kibana’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -KibanaPodSpec - - - - |
-
-
-(Optional)
- -Spec is the Kibana’s PodSpec. - -- - |
-
KibanaSpec
-- -(Appears on: -Kibana) - -
-| Field | -Description | -
|---|---|
-
-template- - -KibanaPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the Kibana pod that will be created. - - - |
-
KubernetesAutodetectionMethod
-(string alias)
-- -(Appears on: -NodeAddressAutodetection) - -
--KubernetesAutodetectionMethod is a method of detecting an IP address based on the Kubernetes API. -
--One of: NodeInternalIP -
-L7LogCollectorDaemonSet
-- -(Appears on: -ApplicationLayerSpec) - -
--L7LogCollectorDaemonSet is the configuration for the L7LogCollector DaemonSet. -
-| Field | -Description | -
|---|---|
-
-spec- - -L7LogCollectorDaemonSetSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the L7LogCollector DaemonSet. - -- - |
-
L7LogCollectorDaemonSetContainer
-- -(Appears on: -L7LogCollectorDaemonSetPodSpec) - -
--L7LogCollectorDaemonSetContainer is a L7LogCollector DaemonSet container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the L7LogCollector DaemonSet container by name. -Supported values are: l7-collector, envoy-proxy, dikastes - - - |
-
-
-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 L7LogCollector DaemonSet container’s resources. -If omitted, the L7LogCollector DaemonSet will use its default value for this container’s resources. - - - |
-
L7LogCollectorDaemonSetInitContainer
-- -(Appears on: -L7LogCollectorDaemonSetPodSpec) - -
--L7LogCollectorDaemonSetInitContainer is a L7LogCollector DaemonSet init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the L7LogCollector DaemonSet init 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 L7LogCollector DaemonSet init container’s resources. -If omitted, the L7LogCollector DaemonSet will use its default value for this init container’s resources. - - - |
-
L7LogCollectorDaemonSetPodSpec
-- -(Appears on: -L7LogCollectorDaemonSetPodTemplateSpec) - -
--L7LogCollectorDaemonSetPodSpec is the L7LogCollector DaemonSet’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]L7LogCollectorDaemonSetInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of L7LogCollector DaemonSet init containers. -If specified, this overrides the specified L7LogCollector DaemonSet init containers. -If omitted, the L7LogCollector DaemonSet will use its default values for its init containers. - - - |
-
-
-containers- - -[]L7LogCollectorDaemonSetContainer - - - - |
-
-
-(Optional)
- -Containers is a list of L7LogCollector DaemonSet containers. -If specified, this overrides the specified L7LogCollector DaemonSet containers. -If omitted, the L7LogCollector DaemonSet will use its default values for its containers. - - - |
-
L7LogCollectorDaemonSetPodTemplateSpec
-- -(Appears on: -L7LogCollectorDaemonSetSpec) - -
--L7LogCollectorDaemonSetPodTemplateSpec is the L7LogCollector DaemonSet’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -L7LogCollectorDaemonSetPodSpec - - - - |
-
-
-(Optional)
- -Spec is the L7LogCollector DaemonSet’s PodSpec. - -- - |
-
L7LogCollectorDaemonSetSpec
-- -(Appears on: -L7LogCollectorDaemonSet) - -
--L7LogCollectorDaemonSetSpec defines configuration for the L7LogCollector DaemonSet. -
-| Field | -Description | -
|---|---|
-
-template- - -L7LogCollectorDaemonSetPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the L7LogCollector DaemonSet pod that will be created. - - - |
-
LinseedDeployment
-- -(Appears on: -LogStorageSpec, -TenantSpec) - -
--LinseedDeployment is the configuration for the linseed Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -LinseedDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the linseed Deployment. - -- - |
-
LinseedDeploymentContainer
-- -(Appears on: -LinseedDeploymentPodSpec) - -
--LinseedDeploymentContainer is a linseed Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the linseed Deployment container by name. -Supported values are: tigera-linseed - - - |
-
-
-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 linseed Deployment container’s resources. -If omitted, the linseed Deployment will use its default value for this container’s resources. - - - |
-
LinseedDeploymentInitContainer
-- -(Appears on: -LinseedDeploymentPodSpec) - -
--LinseedDeploymentInitContainer is a linseed Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the linseed Deployment init container by name. -Supported values are: tigera-secure-linseed-token-tls-key-cert-provisioner,tigera-secure-linseed-cert-key-cert-provisioner - - - |
-
-
-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 linseed Deployment init container’s resources. -If omitted, the linseed Deployment will use its default value for this init container’s resources. - - - |
-
LinseedDeploymentPodSpec
-- -(Appears on: -LinseedDeploymentPodTemplateSpec) - -
--LinseedDeploymentPodSpec is the linseed Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]LinseedDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of linseed init containers. -If specified, this overrides the specified linseed Deployment init containers. -If omitted, the linseed Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]LinseedDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of linseed containers. -If specified, this overrides the specified linseed Deployment containers. -If omitted, the linseed Deployment will use its default values for its containers. - - - |
-
LinseedDeploymentPodTemplateSpec
-- -(Appears on: -LinseedDeploymentSpec) - -
--LinseedDeploymentPodTemplateSpec is the linseed Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -LinseedDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the linseed Deployment’s PodSpec. - -- - |
-
LinseedDeploymentSpec
-- -(Appears on: -LinseedDeployment) - -
--LinseedDeploymentSpec defines configuration for the linseed Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -LinseedDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the linseed Deployment pod that will be created. - - - |
-
LinuxDataplaneOption
-(string alias)
-- -(Appears on: -CalicoNetworkSpec) - -
--LinuxDataplaneOption controls which dataplane is to be used on Linux nodes. -
--One of: Iptables, BPF -
-LogCollectionSpec
-- -(Appears on: -ApplicationLayerSpec) - -
-| Field | -Description | -
|---|---|
-
-collectLogs- - -LogCollectionStatusType - - - - |
-
-
-(Optional)
- -This setting enables or disable log collection. -Allowed values are Enabled or Disabled. - - - |
-
-
-logIntervalSeconds- -int64 - - - |
-
-
-(Optional)
- -Interval in seconds for sending L7 log information for processing. -Default: 5 sec - - - |
-
-
-logRequestsPerInterval- -int64 - - - |
-
-
-(Optional)
- -Maximum number of unique L7 logs that are sent LogIntervalSeconds. -Adjust this to limit the number of L7 logs sent per LogIntervalSeconds -to felix for further processing, use negative number to ignore limits. -Default: -1 - - - |
-
LogCollectionStatusType
-(string alias)
-- -(Appears on: -LogCollectionSpec) - -
-LogCollectorSpec
-- -(Appears on: -LogCollector) - -
--LogCollectorSpec defines the desired state of Tigera flow, audit, and DNS log collection. -
-| Field | -Description | -
|---|---|
-
-additionalStores- - -AdditionalLogStoreSpec - - - - |
-
-
-(Optional)
- -Configuration for exporting flow, audit, and DNS logs to external storage. - - - |
-
-
-additionalSources- - -AdditionalLogSourceSpec - - - - |
-
-
-(Optional)
- -Configuration for importing audit logs from managed kubernetes cluster log sources. - - - |
-
-
-collectProcessPath- - -CollectProcessPathOption - - - - |
-
-
-(Optional)
- -Configuration for enabling/disabling process path collection in flowlogs. -If Enabled, this feature sets hostPID to true in order to read process cmdline. -Default: Enabled - - - |
-
-
-multiTenantManagementClusterNamespace- -string - - - |
-
-
-(Optional)
- -If running as a multi-tenant management cluster, the namespace in which -the management cluster’s tenant services are running. - - - |
-
-
-fluentdDaemonSet- - -FluentdDaemonSet - - - - |
-
-
- -FluentdDaemonSet configures the Fluentd DaemonSet. - - - |
-
-
-eksLogForwarderDeployment- - -EKSLogForwarderDeployment - - - - |
-
-
-(Optional)
- -EKSLogForwarderDeployment configures the EKSLogForwarderDeployment Deployment. - - - |
-
LogCollectorStatus
-- -(Appears on: -LogCollector) - -
--LogCollectorStatus defines the observed state of Tigera flow and DNS log collection -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
LogLevel
-(string alias)
-- -(Appears on: -CNILogging, -EgressGatewaySpec) - -
-LogStorageComponentName
-(string alias)
-- -(Appears on: -LogStorageComponentResource) - -
--LogStorageComponentName CRD enum -
-LogStorageComponentResource
-- -(Appears on: -LogStorageSpec) - -
--The ComponentResource struct associates a ResourceRequirements with a component by name -
-| Field | -Description | -
|---|---|
-
-componentName- - -LogStorageComponentName - - - - |
-
-
- -Deprecated. Please use ECKOperatorStatefulSet. -ComponentName is an enum which identifies the component - - - |
-
-
-resourceRequirements- - -Kubernetes core/v1.ResourceRequirements - - - - |
-
-
- -ResourceRequirements allows customization of limits and requests for compute resources such as cpu and memory. - - - |
-
LogStorageSpec
-- -(Appears on: -LogStorage) - -
--LogStorageSpec defines the desired state of Tigera flow and DNS log storage. -
-| Field | -Description | -
|---|---|
-
-nodes- - -Nodes - - - - |
-
-
- -Nodes defines the configuration for a set of identical Elasticsearch cluster nodes, each of type master, data, and ingest. - - - |
-
-
-indices- - -Indices - - - - |
-
-
-(Optional)
- -Index defines the configuration for the indices in the Elasticsearch cluster. - - - |
-
-
-retention- - -Retention - - - - |
-
-
-(Optional)
- -Retention defines how long data is retained in the Elasticsearch cluster before it is cleared. - - - |
-
-
-storageClassName- -string - - - |
-
-
-(Optional)
- -StorageClassName will populate the PersistentVolumeClaim.StorageClassName that is used to provision disks to the -Tigera Elasticsearch cluster. The StorageClassName should only be modified when no LogStorage is currently -active. We recommend choosing a storage class dedicated to Tigera LogStorage only. Otherwise, data retention -cannot be guaranteed during upgrades. See https://docs.tigera.io/maintenance/upgrading for up-to-date instructions. -Default: tigera-elasticsearch - - - |
-
-
-dataNodeSelector- -map[string]string - - - |
-
-
-(Optional)
- -DataNodeSelector gives you more control over the node that Elasticsearch will run on. The contents of DataNodeSelector will -be added to the PodSpec of the Elasticsearch nodes. For the pod to be eligible to run on a node, the node must have -each of the indicated key-value pairs as labels as well as access to the specified StorageClassName. - - - |
-
-
-componentResources- - -[]LogStorageComponentResource - - - - |
-
-
-(Optional)
- -ComponentResources can be used to customize the resource requirements for each component. -Only ECKOperator is supported for this spec. - - - |
-
-
-eckOperatorStatefulSet- - -ECKOperatorStatefulSet - - - - |
-
-
-(Optional)
- -ECKOperatorStatefulSet configures the ECKOperator StatefulSet. If used in conjunction with the deprecated -ComponentResources, then these overrides take precedence. - - - |
-
-
-kibana- - -Kibana - - - - |
-
-
-(Optional)
- -Kibana configures the Kibana Spec. - - - |
-
-
-linseedDeployment- - -LinseedDeployment - - - - |
-
-
- -LinseedDeployment configures the linseed Deployment. - - - |
-
-
-elasticsearchMetricsDeployment- - -ElasticsearchMetricsDeployment - - - - |
-
-
- -ElasticsearchMetricsDeployment configures the tigera-elasticsearch-metric Deployment. - - - |
-
LogStorageStatus
-- -(Appears on: -LogStorage) - -
--LogStorageStatus defines the observed state of Tigera flow and DNS log storage. -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-elasticsearchHash- -string - - - |
-
-
- -ElasticsearchHash represents the current revision and configuration of the installed Elasticsearch cluster. This -is an opaque string which can be monitored for changes to perform actions when Elasticsearch is modified. - - - |
-
-
-kibanaHash- -string - - - |
-
-
- -KibanaHash represents the current revision and configuration of the installed Kibana dashboard. This -is an opaque string which can be monitored for changes to perform actions when Kibana is modified. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
Logging
-- -(Appears on: -InstallationSpec) - -
-| Field | -Description | -
|---|---|
-
-cni- - -CNILogging - - - - |
-
-
-(Optional)
- -Customized logging specification for calico-cni plugin - - - |
-
ManagementClusterConnectionSpec
-- -(Appears on: -ManagementClusterConnection) - -
--ManagementClusterConnectionSpec defines the desired state of ManagementClusterConnection -
-| Field | -Description | -
|---|---|
-
-managementClusterAddr- -string - - - |
-
-
-(Optional)
- -Specify where the managed cluster can reach the management cluster. Ex.: “10.128.0.10:30449”. A managed cluster -should be able to access this address. This field is used by managed clusters only. - - - |
-
-
-tls- - -ManagementClusterTLS - - - - |
-
-
-(Optional)
- -TLS provides options for configuring how Managed Clusters can establish an mTLS connection with the Management Cluster. - - - |
-
-
-guardianDeployment- - -GuardianDeployment - - - - |
-
-
- -GuardianDeployment configures the guardian Deployment. - - - |
-
ManagementClusterConnectionStatus
-- -(Appears on: -ManagementClusterConnection) - -
--ManagementClusterConnectionStatus defines the observed state of ManagementClusterConnection -
-| Field | -Description | -
|---|---|
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
ManagementClusterSpec
-- -(Appears on: -ManagementCluster) - -
--ManagementClusterSpec defines the desired state of a ManagementCluster -
-| Field | -Description | -
|---|---|
-
-address- -string - - - |
-
-
-(Optional)
- -This field specifies the externally reachable address to which your managed cluster will connect. When a managed -cluster is added, this field is used to populate an easy-to-apply manifest that will connect both clusters. -Valid examples are: “0.0.0.0:31000”, “example.com:32000”, “[::1]:32500” - - - |
-
-
-tls- - -TLS - - - - |
-
-
-(Optional)
- -TLS provides options for configuring how Managed Clusters can establish an mTLS connection with the Management Cluster. - - - |
-
ManagementClusterTLS
-- -(Appears on: -ManagementClusterConnectionSpec) - -
-| Field | -Description | -
|---|---|
-
-ca- - -CAType - - - - |
-
-
- -CA indicates which verification method the tunnel client should use to verify the tunnel server’s identity. - --When left blank or set to ‘Tigera’, the tunnel client will expect a self-signed cert to be included in the certificate bundle -and will expect the cert to have a Common Name (CN) of ‘voltron’. - --When set to ‘Public’, the tunnel client will use its installed system certs and will use the managementClusterAddr to verify the tunnel server’s identity. - --Default: Tigera - - - |
-
ManagerDeployment
-- -(Appears on: -ManagerSpec) - -
--ManagerDeployment is the configuration for the Manager Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -ManagerDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the Manager Deployment. - -- - |
-
ManagerDeploymentContainer
-- -(Appears on: -ManagerDeploymentPodSpec) - -
--ManagerDeploymentContainer is a Manager Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Manager Deployment container by name. -Supported values are: tigera-voltron, tigera-manager, tigera-es-proxy - - - |
-
-
-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 Manager Deployment container’s resources. -If omitted, the Manager Deployment will use its default value for this container’s resources. - - - |
-
ManagerDeploymentInitContainer
-- -(Appears on: -ManagerDeploymentPodSpec) - -
--ManagerDeploymentInitContainer is a Manager Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Manager Deployment init container by name. -Supported values are: manager-tls-key-cert-provisioner, internal-manager-tls-key-cert-provisioner, tigera-voltron-linseed-tls-key-cert-provisioner - - - |
-
-
-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 Manager Deployment init container’s resources. -If omitted, the Manager Deployment will use its default value for this init container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
ManagerDeploymentPodSpec
-- -(Appears on: -ManagerDeploymentPodTemplateSpec) - -
--ManagerDeploymentPodSpec is the Manager Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]ManagerDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of Manager init containers. -If specified, this overrides the specified Manager Deployment init containers. -If omitted, the Manager Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]ManagerDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of Manager containers. -If specified, this overrides the specified Manager Deployment containers. -If omitted, the Manager Deployment will use its default values for its containers. - - - |
-
ManagerDeploymentPodTemplateSpec
-- -(Appears on: -ManagerDeploymentSpec) - -
--ManagerDeploymentPodTemplateSpec is the Manager Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -ManagerDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the Manager Deployment’s PodSpec. - -- - |
-
ManagerDeploymentSpec
-- -(Appears on: -ManagerDeployment) - -
--ManagerDeploymentSpec defines configuration for the Manager Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -ManagerDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the Manager Deployment pod that will be created. - - - |
-
ManagerSpec
-- -(Appears on: -Manager) - -
--ManagerSpec defines configuration for the Calico Enterprise manager GUI. -
-| Field | -Description | -
|---|---|
-
-managerDeployment- - -ManagerDeployment - - - - |
-
-
-(Optional)
- -ManagerDeployment configures the Manager Deployment. - - - |
-
ManagerStatus
-- -(Appears on: -Manager) - -
--ManagerStatus defines the observed state of the Calico Enterprise manager GUI. -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
Metadata
-- -(Appears on: -APIServerDeployment, -APIServerDeploymentPodTemplateSpec, -CSINodeDriverDaemonSet, -CSINodeDriverDaemonSetPodTemplateSpec, -CalicoKubeControllersDeployment, -CalicoKubeControllersDeploymentPodTemplateSpec, -CalicoNodeDaemonSet, -CalicoNodeDaemonSetPodTemplateSpec, -CalicoNodeWindowsDaemonSet, -CalicoNodeWindowsDaemonSetPodTemplateSpec, -CalicoWindowsUpgradeDaemonSet, -CalicoWindowsUpgradeDaemonSetPodTemplateSpec, -TyphaDeployment, -TyphaDeploymentPodTemplateSpec) - -
--Metadata contains the standard Kubernetes labels and annotations fields. -
-| Field | -Description | -
|---|---|
-
-labels- -map[string]string - - - |
-
-
-(Optional)
- -Labels is a map of string keys and values that may match replicaset and -service selectors. Each of these key/value pairs are added to the -object’s labels provided the key does not already exist in the object’s labels. - - - |
-
-
-annotations- -map[string]string - - - |
-
-
-(Optional)
- -Annotations is a map of arbitrary non-identifying metadata. Each of these -key/value pairs are added to the object’s annotations provided the key does not -already exist in the object’s annotations. - - - |
-
MonitorSpec
-- -(Appears on: -Monitor) - -
--MonitorSpec defines the desired state of Tigera monitor. -
-| Field | -Description | -
|---|---|
-
-externalPrometheus- - -ExternalPrometheus - - - - |
-
-
- -ExternalPrometheus optionally configures integration with an external Prometheus for scraping Calico metrics. When -specified, the operator will render resources in the defined namespace. This option can be useful for configuring -scraping from git-ops tools without the need of post-installation steps. - - - |
-
-
-prometheus- - -Prometheus - - - - |
-
-
-(Optional)
- -Prometheus is the configuration for the Prometheus. - - - |
-
-
-alertManager- - -AlertManager - - - - |
-
-
-(Optional)
- -AlertManager is the configuration for the AlertManager. - - - |
-
MonitorStatus
-- -(Appears on: -Monitor) - -
--MonitorStatus defines the observed state of Tigera monitor. -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
MultiInterfaceMode
-(string alias)
-- -(Appears on: -CalicoNetworkSpec) - -
--MultiInterfaceMode describes the method of providing multiple pod interfaces. -
--One of: None, Multus -
-NATOutgoingType
-(string alias)
-- -(Appears on: -IPPool) - -
--NATOutgoingType describe the type of outgoing NAT to use. -
--One of: Enabled, Disabled -
-NativeIP
-(string alias)
-- -(Appears on: -AWSEgressGateway) - -
--NativeIP defines if Egress Gateway pods should have AWS IPs. -When NativeIP is enabled, the IPPools should be backed by AWS subnet. -
-NodeAddressAutodetection
-- -(Appears on: -CalicoNetworkSpec) - -
--NodeAddressAutodetection provides configuration options for auto-detecting node addresses. At most one option -can be used. If no detection option is specified, then IP auto detection will be disabled for this address family and IPs -must be specified directly on the Node resource. -
-| Field | -Description | -
|---|---|
-
-firstFound- -bool - - - |
-
-
-(Optional)
- -FirstFound uses default interface matching parameters to select an interface, performing best-effort -filtering based on well-known interface names. - - - |
-
-
-kubernetes- - -KubernetesAutodetectionMethod - - - - |
-
-
-(Optional)
- -Kubernetes configures Calico to detect node addresses based on the Kubernetes API. - - - |
-
-
-interface- -string - - - |
-
-
-(Optional)
- -Interface enables IP auto-detection based on interfaces that match the given regex. - - - |
-
-
-skipInterface- -string - - - |
-
-
-(Optional)
- -SkipInterface enables IP auto-detection based on interfaces that do not match -the given regex. - - - |
-
-
-canReach- -string - - - |
-
-
-(Optional)
- -CanReach enables IP auto-detection based on which source address on the node is used to reach the -specified IP or domain. - - - |
-
-
-cidrs- -[]string - - - |
-
-
- -CIDRS enables IP auto-detection based on which addresses on the nodes are within -one of the provided CIDRs. - - - |
-
NodeAffinity
-- -(Appears on: -TyphaAffinity) - -
--NodeAffinity is similar to *v1.NodeAffinity, but allows us to limit available schedulers. -
-| Field | -Description | -
|---|---|
-
-preferredDuringSchedulingIgnoredDuringExecution- - -[]Kubernetes core/v1.PreferredSchedulingTerm - - - - |
-
-
-(Optional)
- -The scheduler will prefer to schedule pods to nodes that satisfy -the affinity expressions specified by this field, but it may choose -a node that violates one or more of the expressions. - - - |
-
-
-requiredDuringSchedulingIgnoredDuringExecution- - -Kubernetes core/v1.NodeSelector - - - - |
-
-
-(Optional)
- -WARNING: Please note that if the affinity requirements specified by this field are not met at -scheduling time, the pod will NOT be scheduled onto the node. -There is no fallback to another affinity rules with this setting. -This may cause networking disruption or even catastrophic failure! -PreferredDuringSchedulingIgnoredDuringExecution should be used for affinity -unless there is a specific well understood reason to use RequiredDuringSchedulingIgnoredDuringExecution and -you can guarantee that the RequiredDuringSchedulingIgnoredDuringExecution will always have sufficient nodes to satisfy the requirement. -NOTE: RequiredDuringSchedulingIgnoredDuringExecution is set by default for AKS nodes, -to avoid scheduling Typhas on virtual-nodes. -If the affinity requirements specified by this field cease to be met -at some point during pod execution (e.g. due to an update), the system -may or may not try to eventually evict the pod from its node. - - - |
-
NodeSet
-- -(Appears on: -Nodes) - -
--NodeSets defines configuration specific to each Elasticsearch Node Set -
-| Field | -Description | -
|---|---|
-
-selectionAttributes- - -[]NodeSetSelectionAttribute - - - - |
-
-
- -SelectionAttributes defines K8s node attributes a NodeSet should use when setting the Node Affinity selectors and -Elasticsearch cluster awareness attributes for the Elasticsearch nodes. The list of SelectionAttributes are used -to define Node Affinities and set the node awareness configuration in the running Elasticsearch instance. - - - |
-
NodeSetSelectionAttribute
-- -(Appears on: -NodeSet) - -
--NodeSetSelectionAttribute defines a K8s node “attribute” the Elasticsearch nodes should be aware of. The “Name” and “Value” -are used together to set the “awareness” attributes in Elasticsearch, while the “NodeLabel” and “Value” are used together -to define Node Affinity for the Pods created for the Elasticsearch nodes. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-- - - | -
-
-nodeLabel- -string - - - |
-- - - | -
-
-value- -string - - - |
-- - - | -
Nodes
-- -(Appears on: -LogStorageSpec) - -
--Nodes defines the configuration for a set of identical Elasticsearch cluster nodes, each of type master, data, and ingest. -
-| Field | -Description | -
|---|---|
-
-count- -int64 - - - |
-
-
- -Count defines the number of nodes in the Elasticsearch cluster. - - - |
-
-
-nodeSets- - -[]NodeSet - - - - |
-
-
-(Optional)
- -NodeSets defines configuration specific to each Elasticsearch Node Set - - - |
-
-
-resourceRequirements- - -Kubernetes core/v1.ResourceRequirements - - - - |
-
-
-(Optional)
- -ResourceRequirements defines the resource limits and requirements for the Elasticsearch cluster. - - - |
-
NonPrivilegedType
-(string alias)
-- -(Appears on: -InstallationSpec) - -
--NonPrivilegedType specifies whether Calico runs as permissioned or not -
--One of: Enabled, Disabled -
-OIDCType
-(string alias)
-- -(Appears on: -AuthenticationOIDC) - -
--OIDCType defines how OIDC is configured for Tigera Enterprise. Dex should be the best option for most use-cases. -The Tigera option can help in specific use-cases, for instance, when you are unable to configure a client secret. -One of: Dex, Tigera -
-PacketCaptureAPIDeployment
-- -(Appears on: -PacketCaptureAPISpec) - -
--PacketCaptureAPIDeployment is the configuration for the PacketCaptureAPI Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -PacketCaptureAPIDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the PacketCaptureAPI Deployment. - -- - |
-
PacketCaptureAPIDeploymentContainer
-- -(Appears on: -PacketCaptureAPIDeploymentPodSpec) - -
--PacketCaptureAPIDeploymentContainer is a PacketCaptureAPI Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the PacketCaptureAPI Deployment container by name. -Supported values are: tigera-packetcapture-server - - - |
-
-
-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 PacketCaptureAPI Deployment container’s resources. -If omitted, the PacketCaptureAPI Deployment will use its default value for this container’s resources. - - - |
-
PacketCaptureAPIDeploymentInitContainer
-- -(Appears on: -PacketCaptureAPIDeploymentPodSpec) - -
--PacketCaptureAPIDeploymentInitContainer is a PacketCaptureAPI Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the PacketCaptureAPI Deployment init container by name. -Supported values are: tigera-packetcapture-server-tls-key-cert-provisioner - - - |
-
-
-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 PacketCaptureAPI Deployment init container’s resources. -If omitted, the PacketCaptureAPI Deployment will use its default value for this init container’s resources. - - - |
-
PacketCaptureAPIDeploymentPodSpec
-- -(Appears on: -PacketCaptureAPIDeploymentPodTemplateSpec) - -
--PacketCaptureAPIDeploymentPodSpec is the PacketCaptureAPI Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]PacketCaptureAPIDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of PacketCaptureAPI init containers. -If specified, this overrides the specified PacketCaptureAPI Deployment init containers. -If omitted, the PacketCaptureAPI Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]PacketCaptureAPIDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of PacketCaptureAPI containers. -If specified, this overrides the specified PacketCaptureAPI Deployment containers. -If omitted, the PacketCaptureAPI Deployment will use its default values for its containers. - - - |
-
PacketCaptureAPIDeploymentPodTemplateSpec
-- -(Appears on: -PacketCaptureAPIDeploymentSpec) - -
--PacketCaptureAPIDeploymentPodTemplateSpec is the PacketCaptureAPI Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -PacketCaptureAPIDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the PacketCaptureAPI Deployment’s PodSpec. - -- - |
-
PacketCaptureAPIDeploymentSpec
-- -(Appears on: -PacketCaptureAPIDeployment) - -
--PacketCaptureAPIDeploymentSpec defines configuration for the PacketCaptureAPI Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -PacketCaptureAPIDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the PacketCaptureAPI Deployment pod that will be created. - - - |
-
PacketCaptureAPISpec
-- -(Appears on: -PacketCaptureAPI) - -
--PacketCaptureAPISpec defines configuration for the Packet Capture API. -
-| Field | -Description | -
|---|---|
-
-packetCaptureAPIDeployment- - -PacketCaptureAPIDeployment - - - - |
-
-
-(Optional)
- -PacketCaptureAPIDeployment configures the PacketCaptureAPI Deployment. - - - |
-
PacketCaptureAPIStatus
-- -(Appears on: -PacketCaptureAPI) - -
--PacketCaptureAPIStatus defines the observed state of the Packet Capture API. -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
-
-conditions- - -[]Kubernetes meta/v1.Condition - - - - |
-
-
-(Optional)
- -Conditions represents the latest observed set of conditions for the component. A component may be one or more of -Ready, Progressing, Degraded or other customer types. - - - |
-
PathMatch
-- -(Appears on: -TLSTerminatedRouteSpec) - -
-| Field | -Description | -
|---|---|
-
-path- -string - - - |
-
-
- -Path is the path portion of the URL based on which we proxy. - - - |
-
-
-pathRegexp- -string - - - |
-
-
-(Optional)
- -PathRegexp, if not nil, checks if Regexp matches the path. - - - |
-
-
-pathReplace- -string - - - |
-
-
-(Optional)
- -PathReplace if not nil will be used to replace PathRegexp matches. - - - |
-
PolicyRecommendationDeployment
-- -(Appears on: -PolicyRecommendationSpec) - -
--PolicyRecommendationDeployment is the configuration for the PolicyRecommendation Deployment. -
-| Field | -Description | -
|---|---|
-
-spec- - -PolicyRecommendationDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the PolicyRecommendation Deployment. - -- - |
-
PolicyRecommendationDeploymentContainer
-- -(Appears on: -PolicyRecommendationDeploymentPodSpec) - -
--PolicyRecommendationDeploymentContainer is a PolicyRecommendation Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the PolicyRecommendation Deployment container by name. -Supported values are: policy-recommendation-controller - - - |
-
-
-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 PolicyRecommendation Deployment container’s resources. -If omitted, the PolicyRecommendation Deployment will use its default value for this container’s resources. - - - |
-
PolicyRecommendationDeploymentInitContainer
-- -(Appears on: -PolicyRecommendationDeploymentPodSpec) - -
--PolicyRecommendationDeploymentInitContainer is a PolicyRecommendation Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the PolicyRecommendation Deployment init 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 PolicyRecommendation Deployment init container’s resources. -If omitted, the PolicyRecommendation Deployment will use its default value for this init container’s resources. - - - |
-
PolicyRecommendationDeploymentPodSpec
-- -(Appears on: -PolicyRecommendationDeploymentPodTemplateSpec) - -
--PolicyRecommendationDeploymentPodSpec is the PolicyRecommendation Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]PolicyRecommendationDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of PolicyRecommendation init containers. -If specified, this overrides the specified PolicyRecommendation Deployment init containers. -If omitted, the PolicyRecommendation Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]PolicyRecommendationDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of PolicyRecommendation containers. -If specified, this overrides the specified PolicyRecommendation Deployment containers. -If omitted, the PolicyRecommendation Deployment will use its default values for its containers. - - - |
-
PolicyRecommendationDeploymentPodTemplateSpec
-- -(Appears on: -PolicyRecommendationDeploymentSpec) - -
--PolicyRecommendationDeploymentPodTemplateSpec is the PolicyRecommendation Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-spec- - -PolicyRecommendationDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the PolicyRecommendation Deployment’s PodSpec. - -- - |
-
PolicyRecommendationDeploymentSpec
-- -(Appears on: -PolicyRecommendationDeployment) - -
--PolicyRecommendationDeploymentSpec defines configuration for the PolicyRecommendation Deployment. -
-| Field | -Description | -
|---|---|
-
-template- - -PolicyRecommendationDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the PolicyRecommendation Deployment pod that will be created. - - - |
-
PolicyRecommendationSpec
-- -(Appears on: -PolicyRecommendation) - -
--PolicyRecommendationSpec defines configuration for the Calico Enterprise Policy Recommendation -service. -
-| Field | -Description | -
|---|---|
-
-policyRecommendationDeployment- - -PolicyRecommendationDeployment - - - - |
-
-
-(Optional)
- -PolicyRecommendation configures the PolicyRecommendation Deployment. - - - |
-
PolicyRecommendationStatus
-- -(Appears on: -PolicyRecommendation) - -
--PolicyRecommendationStatus defines the observed state of Tigera policy recommendation. -
-| Field | -Description | -
|---|---|
-
-state- -string - - - |
-
-
- -State provides user-readable status. - - - |
-
ProductVariant
-(string alias)
-- -(Appears on: -InstallationSpec, -InstallationStatus) - -
--ProductVariant represents the variant of the product. -
--One of: Calico, TigeraSecureEnterprise -
-Prometheus
-- -(Appears on: -MonitorSpec) - -
-| Field | -Description | -
|---|---|
-
-spec- - -PrometheusSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the Prometheus. - -- - |
-
PrometheusContainer
-- -(Appears on: -CommonPrometheusFields) - -
--PrometheusContainer is a Prometheus container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the Prometheus Deployment container by name. -Supported values are: authn-proxy - - - |
-
-
-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 Prometheus container’s resources. -If omitted, the Prometheus will use its default value for this container’s resources. - - - |
-
PrometheusSpec
-- -(Appears on: -Prometheus) - -
-| Field | -Description | -
|---|---|
-
-commonPrometheusFields- - -CommonPrometheusFields - - - - |
-
-
- -CommonPrometheusFields are the options available to both the Prometheus server and agent. - - - |
-
PromptType
-(string alias)
-- -(Appears on: -AuthenticationOIDC) - -
--PromptType is a value that specifies whether the identity provider prompts the end user for re-authentication and -consent. -One of: None, Login, Consent, SelectAccount. -
-Provider
-(string alias)
-- -(Appears on: -InstallationSpec) - -
--Provider represents a particular provider or flavor of Kubernetes. Valid options -are: EKS, GKE, AKS, RKE2, OpenShift, DockerEnterprise, TKG. -
-Retention
-- -(Appears on: -LogStorageSpec) - -
--Retention defines how long data is retained in an Elasticsearch cluster before it is cleared. -
-| Field | -Description | -
|---|---|
-
-flows- -int32 - - - |
-
-
-(Optional)
- -Flows configures the retention period for flow logs, in days. Logs written on a day that started at least this long ago -are removed. To keep logs for at least x days, use a retention period of x+1. -Default: 8 - - - |
-
-
-auditReports- -int32 - - - |
-
-
-(Optional)
- -AuditReports configures the retention period for audit logs, in days. Logs written on a day that started at least this long ago are -removed. To keep logs for at least x days, use a retention period of x+1. -Default: 91 - - - |
-
-
-snapshots- -int32 - - - |
-
-
-(Optional)
- -Snapshots configures the retention period for snapshots, in days. Snapshots are periodic captures -of resources which along with audit events are used to generate reports. -Consult the Compliance Reporting documentation for more details on snapshots. -Logs written on a day that started at least this long ago are -removed. To keep logs for at least x days, use a retention period of x+1. -Default: 91 - - - |
-
-
-complianceReports- -int32 - - - |
-
-
-(Optional)
- -ComplianceReports configures the retention period for compliance reports, in days. Reports are output -from the analysis of the system state and audit events for compliance reporting. -Consult the Compliance Reporting documentation for more details on reports. -Logs written on a day that started at least this long ago are -removed. To keep logs for at least x days, use a retention period of x+1. -Default: 91 - - - |
-
-
-dnsLogs- -int32 - - - |
-
-
-(Optional)
- -DNSLogs configures the retention period for DNS logs, in days. Logs written on a day that started at least this long ago -are removed. To keep logs for at least x days, use a retention period of x+1. -Default: 8 - - - |
-
-
-bgpLogs- -int32 - - - |
-
-
-(Optional)
- -BGPLogs configures the retention period for BGP logs, in days. Logs written on a day that started at least this long ago -are removed. To keep logs for at least x days, use a retention period of x+1. -Default: 8 - - - |
-
S3StoreSpec
-- -(Appears on: -AdditionalLogStoreSpec) - -
--S3StoreSpec defines configuration for exporting logs to Amazon S3. -
-| Field | -Description | -
|---|---|
-
-region- -string - - - |
-
-
- -AWS Region of the S3 bucket - - - |
-
-
-bucketName- -string - - - |
-
-
- -Name of the S3 bucket to send logs - - - |
-
-
-bucketPath- -string - - - |
-
-
- -Path in the S3 bucket where to send logs - - - |
-
SNIMatch
-- -(Appears on: -TLSPassThroughRouteSpec) - -
-| Field | -Description | -
|---|---|
-
-serverName- -string - - - |
-
-
- -ServerName is used to match the server name for the request. - - - |
-
ServiceMonitor
-- -(Appears on: -ExternalPrometheus) - -
-| Field | -Description | -
|---|---|
-
-labels- -map[string]string - - - |
-
-
- -Labels are the metadata.labels of the ServiceMonitor. When combined with spec.serviceMonitorSelector.matchLabels -on your prometheus instance, the service monitor will automatically be picked up. -Default: k8s-app=tigera-prometheus - - - |
-
-
-endpoints- - -[]Endpoint - - - - |
-
-
- -The endpoints to scrape. This struct contains a subset of the Endpoint as defined in the prometheus docs. Fields -related to connecting to our Prometheus server are automatically set by the operator. - - - |
-
SplunkStoreSpec
-- -(Appears on: -AdditionalLogStoreSpec) - -
--SplunkStoreSpec defines configuration for exporting logs to splunk. -
-| Field | -Description | -
|---|---|
-
-endpoint- -string - - - |
-
-
-
-Location for splunk’s http event collector end point. example |
-
StatusConditionType
-(string alias)
-- -(Appears on: -TigeraStatusCondition) - -
--StatusConditionType is a type of condition that may apply to a particular component. -
-Sysctl
-- -(Appears on: -CalicoNetworkSpec) - -
-| Field | -Description | -
|---|---|
-
-key- -string - - - |
-- - - | -
-
-value- -string - - - |
-- - - | -
SyslogLogType
-(string alias)
-- -(Appears on: -SyslogStoreSpec) - -
--SyslogLogType represents the allowable log types for syslog. -Allowable values are Audit, DNS, Flows and IDSEvents. -* Audit corresponds to audit logs for both Kubernetes resources and Enterprise custom resources. -* DNS corresponds to DNS logs generated by Calico node. -* Flows corresponds to flow logs generated by Calico node. -* IDSEvents corresponds to event logs for the intrusion detection system (anomaly detection, suspicious IPs, suspicious domains and global alerts). -
-SyslogStoreSpec
-- -(Appears on: -AdditionalLogStoreSpec) - -
--SyslogStoreSpec defines configuration for exporting logs to syslog. -
-| Field | -Description | -
|---|---|
-
-endpoint- -string - - - |
-
-
- -Location of the syslog server. example: tcp://1.2.3.4:601 - - - |
-
-
-packetSize- -int32 - - - |
-
-
-(Optional)
- -PacketSize defines the maximum size of packets to send to syslog. -In general this is only needed if you notice long logs being truncated. -Default: 1024 - - - |
-
-
-logTypes- - -[]SyslogLogType - - - - |
-
-
- -If no values are provided, the list will be updated to include log types Audit, DNS and Flows. -Default: Audit, DNS, Flows - - - |
-
-
-encryption- - -EncryptionOption - - - - |
-
-
-(Optional)
- -Encryption configures traffic encryption to the Syslog server. -Default: None - - - |
-
TLS
-- -(Appears on: -ManagementClusterSpec) - -
-| Field | -Description | -
|---|---|
-
-secretName- -string - - - |
-
-
-(Optional)
- -SecretName indicates the name of the secret in the tigera-operator namespace that contains the private key and certificate that the management cluster uses when it listens for incoming connections. - --When set to tigera-management-cluster-connection voltron will use the same cert bundle which Guardian client certs are signed with. - --When set to manager-tls, voltron will use the same cert bundle which Manager UI is served with. -This cert bundle must be a publicly signed cert created by the user. -Note that Tigera Operator will generate a self-signed manager-tls cert if one does not exist, -and use of that cert will result in Guardian being unable to verify Voltron’s identity. - --If changed on a running cluster with connected managed clusters, all managed clusters will disconnect as they will no longer be able to verify Voltron’s identity. -To reconnect existing managed clusters, change the tls.ca of the managed clusters’ ManagementClusterConnection resource. - --One of: tigera-management-cluster-connection, manager-tls - --Default: tigera-management-cluster-connection - - - |
-
TLSPassThroughRouteSpec
-- -(Appears on: -TLSPassThroughRoute) - -
-| Field | -Description | -
|---|---|
-
-target- - -TargetType - - - - |
-- - - | -
-
-sniMatch- - -SNIMatch - - - - |
-
-
- -SNIMatch is used to match requests based on the server name for the intended destination server. Matching requests -will be proxied to the Destination. - - - |
-
-
-destination- -string - - - |
-
-
- -Destination is the destination url to proxy the request to. - - - |
-
TLSTerminatedRouteSpec
-- -(Appears on: -TLSTerminatedRoute) - -
-| Field | -Description | -
|---|---|
-
-target- - -TargetType - - - - |
-- - - | -
-
-pathMatch- - -PathMatch - - - - |
-
-
- -PathMatch is used to match requests based on what’s in the path. Matching requests will be proxied to the Destination -defined in this structure. - - - |
-
-
-destination- -string - - - |
-
-
- -Destination is the destination URL where matching traffic is routed to. - - - |
-
-
-caBundle- - -Kubernetes core/v1.ConfigMapKeySelector - - - - |
-
-
- -CABundle is where we read the CA bundle from to authenticate the -destination (if non-empty) - - - |
-
-
-mtlsCert- - -Kubernetes core/v1.SecretKeySelector - - - - |
-
-
-(Optional)
- -ForwardingMTLSCert is the certificate used for mTLS between voltron and the destination. Either both ForwardingMTLSCert -and ForwardingMTLSKey must be specified, or neither can be specified. - - - |
-
-
-mtlsKey- - -Kubernetes core/v1.SecretKeySelector - - - - |
-
-
-(Optional)
- -ForwardingMTLSKey is the key used for mTLS between voltron and the destination. Either both ForwardingMTLSCert -and ForwardingMTLSKey must be specified, or neither can be specified. - - - |
-
-
-unauthenticated- -bool - - - |
-
-
-(Optional)
- -Unauthenticated says whether the request should go through authentication. This is only applicable if the Target -is UI. - - - |
-
TargetType
-(string alias)
-- -(Appears on: -TLSPassThroughRouteSpec, -TLSTerminatedRouteSpec) - -
-TenantElasticSpec
-- -(Appears on: -TenantSpec) - -
-| Field | -Description | -
|---|---|
-
-url- -string - - - |
-- - - | -
-
-kibanaURL- -string - - - |
-- - - | -
-
-mutualTLS- -bool - - - |
-- - - | -
TenantSpec
-- -(Appears on: -Tenant) - -
-| Field | -Description | -
|---|---|
-
-id- -string - - - |
-
-
- -ID is the unique identifier for this tenant. - - - |
-
-
-name- -string - - - |
-
-
- -Name is a human readable name for this tenant. - - - |
-
-
-indices- - -[]Index - - - - |
-
-
- -Indices defines the how to store a tenant’s data - - - |
-
-
-elastic- - -TenantElasticSpec - - - - |
-
-
- -Elastic configures per-tenant ElasticSearch and Kibana parameters. -This field is required for clusters using external ES. - - - |
-
-
-controlPlaneReplicas- -int32 - - - |
-
-
-(Optional)
- -ControlPlaneReplicas defines how many replicas of the control plane core components will be deployed -in the Tenant’s namespace. Defaults to the controlPlaneReplicas in Installation CR - - - |
-
-
-linseedDeployment- - -LinseedDeployment - - - - |
-
-
- -LinseedDeployment configures the linseed Deployment. - - - |
-
-
-esKubeControllerDeployment- - -CalicoKubeControllersDeployment - - - - |
-
-
- -ESKubeControllerDeployment configures the ESKubeController Deployment. - - - |
-
-
-dashboardsJob- - -DashboardsJob - - - - |
-
-
- -DashboardsJob configures the Dashboards job - - - |
-
TenantStatus
-- -(Appears on: -Tenant) - -
-TigeraStatusCondition
-- -(Appears on: -TigeraStatusStatus) - -
--TigeraStatusCondition represents a condition attached to a particular component. -
-| Field | -Description | -
|---|---|
-
-type- - -StatusConditionType - - - - |
-
-
- -The type of condition. May be Available, Progressing, or Degraded. - - - |
-
-
-status- - -ConditionStatus - - - - |
-
-
- -The status of the condition. May be True, False, or Unknown. - - - |
-
-
-lastTransitionTime- - -Kubernetes meta/v1.Time - - - - |
-
-
- -The timestamp representing the start time for the current status. - - - |
-
-
-reason- -string - - - |
-
-
- -A brief reason explaining the condition. - - - |
-
-
-message- -string - - - |
-
-
- -Optionally, a detailed message providing additional context. - - - |
-
-
-observedGeneration- -int64 - - - |
-
-
-(Optional)
- -observedGeneration represents the generation that the condition was set based upon. -For instance, if generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date -with respect to the current state of the instance. - - - |
-
TigeraStatusReason
-(string alias)
--TigeraStatusReason represents the reason for a particular condition. -
-TigeraStatusSpec
-- -(Appears on: -TigeraStatus) - -
--TigeraStatusSpec defines the desired state of TigeraStatus -
-TigeraStatusStatus
-- -(Appears on: -TigeraStatus) - -
--TigeraStatusStatus defines the observed state of TigeraStatus -
-| Field | -Description | -
|---|---|
-
-conditions- - -[]TigeraStatusCondition - - - - |
-
-
- -Conditions represents the latest observed set of conditions for this component. A component may be one or more of -Available, Progressing, or Degraded. - - - |
-
TyphaAffinity
-- -(Appears on: -InstallationSpec) - -
--Deprecated. Please use TyphaDeployment instead. -TyphaAffinity allows configuration of node affinity characteristics for Typha pods. -
-| Field | -Description | -
|---|---|
-
-nodeAffinity- - -NodeAffinity - - - - |
-
-
-(Optional)
- -NodeAffinity describes node affinity scheduling rules for typha. - - - |
-
TyphaDeployment
-- -(Appears on: -InstallationSpec) - -
--TyphaDeployment is the configuration for the typha Deployment. -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to the Deployment. - - - |
-
-
-spec- - -TyphaDeploymentSpec - - - - |
-
-
-(Optional)
- -Spec is the specification of the typha Deployment. - -- - |
-
TyphaDeploymentContainer
-- -(Appears on: -TyphaDeploymentPodSpec) - -
--TyphaDeploymentContainer is a typha Deployment container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the typha Deployment container by name. -Supported values are: calico-typha - - - |
-
-
-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 typha Deployment container’s resources. -If omitted, the typha Deployment will use its default value for this container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
TyphaDeploymentInitContainer
-- -(Appears on: -TyphaDeploymentPodSpec) - -
--TyphaDeploymentInitContainer is a typha Deployment init container. -
-| Field | -Description | -
|---|---|
-
-name- -string - - - |
-
-
- -Name is an enum which identifies the typha Deployment init container by name. -Supported values are: typha-certs-key-cert-provisioner - - - |
-
-
-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 typha Deployment init container’s resources. -If omitted, the typha Deployment will use its default value for this init container’s resources. -If used in conjunction with the deprecated ComponentResources, then this value takes precedence. - - - |
-
TyphaDeploymentPodSpec
-- -(Appears on: -TyphaDeploymentPodTemplateSpec) - -
--TyphaDeploymentPodSpec is the typha Deployment’s PodSpec. -
-| Field | -Description | -
|---|---|
-
-initContainers- - -[]TyphaDeploymentInitContainer - - - - |
-
-
-(Optional)
- -InitContainers is a list of typha init containers. -If specified, this overrides the specified typha Deployment init containers. -If omitted, the typha Deployment will use its default values for its init containers. - - - |
-
-
-containers- - -[]TyphaDeploymentContainer - - - - |
-
-
-(Optional)
- -Containers is a list of typha containers. -If specified, this overrides the specified typha Deployment containers. -If omitted, the typha Deployment will use its default values for its containers. - - - |
-
-
-affinity- - -Kubernetes core/v1.Affinity - - - - |
-
-
-(Optional)
- -Affinity is a group of affinity scheduling rules for the typha pods. -If specified, this overrides any affinity that may be set on the typha Deployment. -If omitted, the typha Deployment will use its default value for affinity. -If used in conjunction with the deprecated TyphaAffinity, then this value takes precedence. -WARNING: Please note that this field will override the default calico-typha Deployment affinity. - - - |
-
-
-nodeSelector- -map[string]string - - - |
-
-
- -NodeSelector is the calico-typha pod’s scheduling constraints. -If specified, each of the key/value pairs are added to the calico-typha Deployment nodeSelector provided -the key does not already exist in the object’s nodeSelector. -If omitted, the calico-typha Deployment will use its default value for nodeSelector. -WARNING: Please note that this field will modify the default calico-typha Deployment nodeSelector. - - - |
-
-
-terminationGracePeriodSeconds- -int64 - - - |
-
-
-(Optional)
- -Optional duration in seconds the pod needs to terminate gracefully. May be decreased in delete request. -Value must be non-negative integer. The value zero indicates stop immediately via -the kill signal (no opportunity to shut down). -If this value is nil, the default grace period will be used instead. -The grace period is the duration in seconds after the processes running in the pod are sent -a termination signal and the time when the processes are forcibly halted with a kill signal. -Set this value longer than the expected cleanup time for your process. -Defaults to 30 seconds. - - - |
-
-
-topologySpreadConstraints- - -[]Kubernetes core/v1.TopologySpreadConstraint - - - - |
-
-
-(Optional)
- -TopologySpreadConstraints describes how a group of pods ought to spread across topology -domains. Scheduler will schedule pods in a way which abides by the constraints. -All topologySpreadConstraints are ANDed. - - - |
-
-
-tolerations- - -[]Kubernetes core/v1.Toleration - - - - |
-
-
-(Optional)
- -Tolerations is the typha pod’s tolerations. -If specified, this overrides any tolerations that may be set on the typha Deployment. -If omitted, the typha Deployment will use its default value for tolerations. -WARNING: Please note that this field will override the default calico-typha Deployment tolerations. - - - |
-
TyphaDeploymentPodTemplateSpec
-- -(Appears on: -TyphaDeploymentSpec) - -
--TyphaDeploymentPodTemplateSpec is the typha Deployment’s PodTemplateSpec -
-| Field | -Description | -
|---|---|
-
-metadata- - -Metadata - - - - |
-
-
-(Optional)
- -Metadata is a subset of a Kubernetes object’s metadata that is added to -the pod’s metadata. - - - |
-
-
-spec- - -TyphaDeploymentPodSpec - - - - |
-
-
-(Optional)
- -Spec is the typha Deployment’s PodSpec. - -- - |
-
TyphaDeploymentSpec
-- -(Appears on: -TyphaDeployment) - -
--TyphaDeploymentSpec defines configuration for the typha Deployment. -
-| Field | -Description | -
|---|---|
-
-minReadySeconds- -int32 - - - |
-
-
-(Optional)
- -MinReadySeconds is the minimum number of seconds for which a newly created Deployment 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 typha Deployment. -If omitted, the typha Deployment will use its default value for minReadySeconds. - - - |
-
-
-template- - -TyphaDeploymentPodTemplateSpec - - - - |
-
-
-(Optional)
- -Template describes the typha Deployment pod that will be created. - - - |
-
-
-strategy- - -TyphaDeploymentStrategy - - - - |
-
-
-(Optional)
- -The deployment strategy to use to replace existing pods with new ones. - - - |
-
TyphaDeploymentStrategy
-- -(Appears on: -TyphaDeploymentSpec) - -
--TyphaDeploymentStrategy describes how to replace existing pods with new ones. Only RollingUpdate is supported -at this time so the Type field is not exposed. -
-| Field | -Description | -
|---|---|
-
-rollingUpdate- - -Kubernetes apps/v1.RollingUpdateDeployment - - - - |
-
-
-(Optional)
- -Rolling update config params. Present only if DeploymentStrategyType = -RollingUpdate. -to be. - - - |
-
UserMatch
-- -(Appears on: -GroupSearch) - -
--UserMatch when the value of a UserAttribute and a GroupAttribute match, a user belongs to the group. -
-| Field | -Description | -
|---|---|
-
-userAttribute- -string - - - |
-
-
- -The attribute of a user that links it to a group. - - - |
-
-
-groupAttribute- -string - - - |
-
-
- -The attribute of a group that links it to a user. - - - |
-
UserSearch
-- -(Appears on: -AuthenticationLDAP) - -
--User entry search configuration to match the credentials with a user. -
-| Field | -Description | -
|---|---|
-
-baseDN- -string - - - |
-
-
- -BaseDN to start the search from. For example “cn=users,dc=example,dc=com” - - - |
-
-
-filter- -string - - - |
-
-
-(Optional)
- -Optional filter to apply when searching the directory. For example “(objectClass=person)” - - - |
-
-
-nameAttribute- -string - - - |
-
-
-(Optional)
- -A mapping of the attribute that is used as the username. This attribute can be used to apply RBAC to a user. -Default: uid - - - |
-
WAFStatusType
-(string alias)
-- -(Appears on: -ApplicationLayerSpec) - -
-WindowsDataplaneOption
-(string alias)
-- -(Appears on: -CalicoNetworkSpec) - -
-WindowsNodeSpec
-- -(Appears on: -InstallationSpec) - -
-| Field | -Description | -
|---|---|
-
-cniBinDir- -string - - - |
-
-
-(Optional)
- -CNIBinDir is the path to the CNI binaries directory on Windows, it must match what is used as ‘bin_dir’ under -[plugins] -[plugins.“io.containerd.grpc.v1.cri”] -[plugins.“io.containerd.grpc.v1.cri”.cni] -on the containerd ‘config.toml’ file on the Windows nodes. - - - |
-
-
-cniConfigDir- -string - - - |
-
-
-(Optional)
- -CNIConfigDir is the path to the CNI configuration directory on Windows, it must match what is used as ‘conf_dir’ under -[plugins] -[plugins.“io.containerd.grpc.v1.cri”] -[plugins.“io.containerd.grpc.v1.cri”.cni] -on the containerd ‘config.toml’ file on the Windows nodes. - - - |
-
-
-cniLogDir- -string - - - |
-
-
-(Optional)
- -CNILogDir is the path to the Calico CNI logs directory on Windows. - - - |
-
-
-vxlanMACPrefix- -string - - - |
-
-
-(Optional)
- -VXLANMACPrefix is the prefix used when generating MAC addresses for virtual NICs - - - |
-
-
-vxlanAdapter- -string - - - |
-
-
-(Optional)
- -VXLANAdapter is the Network Adapter used for VXLAN, leave blank for primary NIC - - - |
-
diff --git a/calico-cloud_versioned_docs/version-20-1/reference/installation/_ia-api.mdx b/calico-cloud_versioned_docs/version-20-1/reference/installation/_ia-api.mdx deleted file mode 100644 index 8d38a203c5..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/reference/installation/_ia-api.mdx +++ /dev/null @@ -1,721 +0,0 @@ -
-Packages: -
- -image-assurance.operator.tigera.io/v1
-
-
-Resource Types:
--API Schema definitions for configuring the installation of Image Assurance -
-ClusterScannerStatusType
-(string alias)
-- -(Appears on: -ImageAssuranceSpec) - -
-CrawdadDaemonSet
-- -(Appears on: -ImageAssuranceSpec) - -
-| Field | -Description | -
|---|---|
-
-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. -
-| Field | -Description | -
|---|---|
-
-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. -
-| Field | -Description | -
|---|---|
-
-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 -
-| Field | -Description | -
|---|---|
-
-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. -
-| Field | -Description | -
|---|---|
-
-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. -
-| Field | -Description | -
|---|---|
-
-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 -
-| Field | -Description | -||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
-
-metadata- - -Kubernetes meta/v1.ObjectMeta - - - - |
-
-
-Refer to the Kubernetes API documentation for the fields of the
-metadata field.
-
- |
-||||||||||
-
-spec- - -ImageAssuranceSpec - - - - |
-
-
- - -
|
-||||||||||
-
-status- - -ImageAssuranceStatus - - - - |
-- - - | -
ImageAssuranceSpec
-- -(Appears on: -ImageAssurance) - -
--ImageAssuranceSpec configures Image Assurance monitoring and tooling in a kubernetes cluster. -
-| Field | -Description | -
|---|---|
-
-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_versioned_docs/version-20-1/reference/installation/api.mdx b/calico-cloud_versioned_docs/version-20-1/reference/installation/api.mdx deleted file mode 100644 index c897085ea7..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/reference/installation/api.mdx +++ /dev/null @@ -1,11 +0,0 @@ ---- -description: Installation API reference ---- - -# Installation reference - -import API from '@site/calico-cloud_versioned_docs/version-20-1/reference/installation/_api.mdx'; - -The Kubernetes resources below configure $[prodname] installation when using the operator. Each resource is responsible for installing and configuring a different subsystem of $[prodname] during installation. Most options can be modified on a running cluster using `kubectl`. - -
For large community, value should be `aa:nn:mm` format, where `aa`, `nn` and `mm` are all 32 bit integers.
Where `aa` is an AS Number, `nn` and `mm` are per-AS identifier. | string | - -### prefixAdvertisements - -| Field | Description | Accepted Values | Schema | -| ----------- | ----------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------- | -| cidr | CIDR for which properties should be advertised. | `cidr: XXX.XXX.XXX.XXX/XX` | string | -| communities | BGP communities to be advertised. | Communities can be list of either community names already defined in [communities](#communities) or community value of format `aa:nn` or `aa:nn:mm`.
For standard community, value should be in `aa:nn` format, where both `aa` and `nn` are 16 bit integers.
For large community, value should be `aa:nn:mm` format, where `aa`, `nn` and `mm` are all 32 bit integers.
Where `aa` is an AS Number, `nn` and `mm` are per-AS identifier. | List of string | - -## Supported operations - -| Datastore type | Create | Delete | Delete (Global `default`) | Update | Get/List | Notes | -| --------------------- | ------ | ------ | ------------------------- | ------ | -------- | ----- | -| Kubernetes API server | Yes | Yes | No | Yes | Yes | diff --git a/calico-cloud_versioned_docs/version-20-1/reference/resources/bgpfilter.mdx b/calico-cloud_versioned_docs/version-20-1/reference/resources/bgpfilter.mdx deleted file mode 100644 index 26ca0c89f1..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/reference/resources/bgpfilter.mdx +++ /dev/null @@ -1,118 +0,0 @@ ---- -description: API for this Calico Cloud resource. ---- - -# BGP Filter - -A BGP filter resource (`BGPFilter`) represents a way to control -routes imported by and exported to BGP peers specified using a -BGP peer resource (`BGPPeer`). - -The BGPFilter rules are applied sequentially: the `action` for -the **first** rule that matches an address to its `cidr` + -`matchOperator` is executed immediately. If an address does not -match any explicit BGP filter rule, the default action is -`accept`. - -In order for a BGPFilter to be used in a BGP peering, its `name` -must be added to `filters` of the corresponding BGPPeer resource. - -For `kubectl` commands, the following case-sensitive aliases may -be used to specify the resource type on the CLI: `bgpfilters.crd.projectcalico.org` - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPFilter -metadata: - name: my-filter -spec: - exportV4: - - action: Accept - matchOperator: In - cidr: 77.0.0.0/16 - - action: Reject - matchOperator: NotIn - cidr: 88.0.0.0/16 - importV4: - - action: Reject - matchOperator: NotIn - cidr: 44.0.0.0/16 - exportV6: - - action: Reject - matchOperator: NotEqual - cidr: 9000::0/64 - importV6: - - action: Accept - matchOperator: Equal - cidr: 5000::0/64 - - action: Reject - matchOperator: NotIn - cidr: 5000::0/64 -``` - -## BGP filter definition - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPFilter -metadata: - name: my-filter -spec: - exportV4: - - action: Accept - matchOperator: In - cidr: 77.0.0.0/16 - importV4: - - action: Accept - matchOperator: NotIn - cidr: 44.0.0.0/16 - exportV6: - - action: Accept - matchOperator: Equal - cidr: 9000::0/64 - importV6: - - action: Accept - matchOperator: NotEqual - cidr: 5000::0/64 -``` - -## BGP filter definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | ------------------------------------------------------------------ | --------------------------------------------------- | ------ | -| name | Unique name to describe this resource instance. Must be specified. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| -------- | -------------------------------------------------- | --------------- | ----------------------------------------- | ------- | -| exportV4 | List of v4 CIDRs and export action | | [BGP Filter Rule v4](#bgp-filter-rule-v4) | | -| importV4 | List of v4 CIDRs and import action | | [BGP Filter Rule v4](#bgp-filter-rule-v4) | | -| exportV6 | List of v6 CIDRs and export action | | [BGP Filter Rule v6](#bgp-filter-rule-v6) | | -| importV6 | List of v6 CIDRs and import action | | [BGP Filter Rule v6](#bgp-filter-rule-v6) | | - -### BGP Filter Rule v4 - -| Field | Description | Accepted Values | Schema | Default | -| ------------- | ----------------------------------------- | ---------------------------------- | ------ | ------- | -| cidr | IPv4 range | A valid IPv4 CIDR | string | | -| matchOperator | Method by which to match candidate routes | `In`, `NotIn`, `Equal`, `NotEqual` | string | | -| action | Action to be taken for this CIDR | `Accept` or `Reject` | string | | - -### BGP Filter Rule v6 - -| Field | Description | Accepted Values | Schema | Default | -| ------------- | ----------------------------------------- | ---------------------------------- | ------ | ------- | -| cidr | IPv6 range | A valid IPv6 CIDR | string | | -| matchOperator | Method by which to match candidate routes | `In`, `NotIn`, `Equal`, `NotEqual` | string | | -| action | Action to be taken for this CIDR | `Accept` or `Reject` | string | | - -## Supported operations - -| Datastore type | Create/Delete | Update | Get/List | Notes | -| --------------------- | ------------- | ------ | -------- | ----- | -| Kubernetes API server | Yes | Yes | Yes | | diff --git a/calico-cloud_versioned_docs/version-20-1/reference/resources/bgppeer.mdx b/calico-cloud_versioned_docs/version-20-1/reference/resources/bgppeer.mdx deleted file mode 100644 index af831f88ce..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/reference/resources/bgppeer.mdx +++ /dev/null @@ -1,118 +0,0 @@ ---- -description: API for this Calico Cloud resource. ---- - -# BGP peer - -import Selectors from '@site/calico-cloud_versioned_docs/version-20-1/_includes/content/_selectors.mdx'; - -A BGP peer resource (`BGPPeer`) represents a remote BGP peer with -which the node(s) in a $[prodname] cluster will peer. -Configuring BGP peers allows you to peer a $[prodname] network -with your datacenter fabric (e.g. ToR). For more -information on cluster layouts, see $[prodname]'s documentation on -[$[prodname] over IP fabrics](../architecture/design/l3-interconnect-fabric.mdx). - -For `kubectl` commands, the following case-insensitive aliases may be used to specify the resource type on the CLI: `bgppeer.projectcalico.org`, `bgppeers.projectcalico.org` as well as abbreviations such as `bgppeer.p` and `bgppeers.p`. - -## Sample YAML - -```yaml -apiVersion: projectcalico.org/v3 -kind: BGPPeer -metadata: - name: some.name -spec: - node: rack1-host1 - peerIP: 192.168.1.1 - asNumber: 63400 -``` - -## BGP peer definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | ------------------------------------------------------------------ | --------------------------------------------------- | ------ | -| name | Unique name to describe this resource instance. Must be specified. | Alphanumeric string with optional `.`, `_`, or `-`. | string | - -### Spec - -| Field | Description | Accepted Values | Schema | Default | -| ------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | --------------------------- | ---------------------------------------------------------------------------- | -| node | If specified, the scope is node level, otherwise the scope is global. | The hostname of the node to which this peer applies. | string | | -| peerIP | The IP address of this peer and an optional port number. If port number is not set, and peer is Calico node with `listenPort` set, then `listenPort` is used. | Valid IPv4 or IPv6 address. If port number is set use, `IPv4:port` or `[IPv6]:port` format. | string | | -| asNumber | The remote AS Number of the peer. | A valid AS Number, may be specified in dotted notation. | integer/string | -| nodeSelector | Selector for the nodes that should have this peering. When this is set, the `node` field must be empty. | | [selector](#selector) | -| peerSelector | Selector for the remote nodes to peer with. When this is set, the `peerIP` and `asNumber` fields must be empty. | | [selector](#selector) | -| keepOriginalNextHop | Maintain and forward the original next hop BGP route attribute to a specific Peer within a different AS. | | boolean | -| extensions | Additional mapping of keys and values. Used for setting values in custom BGP configurations. | valid strings for both keys and values | map | | -| password | [BGP password](../../operations/comms/secure-bgp.mdx) for the peerings generated by this BGPPeer resource. | | [BGPPassword](#bgppassword) | `nil` (no password) | -| sourceAddress | Specifies whether and how to configure a source address for the peerings generated by this BGPPeer resource. Default value "UseNodeIP" means to configure the node IP as the source address. "None" means not to configure a source address. | "UseNodeIP", "None" | string | "UseNodeIP" | -| failureDetectionMode | Specifies whether and how to detect loss of connectivity on the peerings generated by this BGPPeer resource. Default value "None" means nothing beyond BGP's own (slow) hold timer. "BFDIfDirectlyConnected" means to use BFD when the peer is directly connected. | "None", "BFDIfDirectlyConnected" | string | "None" | -| restartMode | Specifies restart behaviour to configure on the peerings generated by this BGPPeer resource. Default value "GracefulRestart" means traditional graceful restart. "LongLivedGracefulRestart" means LLGR according to draft-uttaro-idr-bgp-persistence-05. | "GracefulRestart", "LongLivedGracefulRestart" | string | "GracefulRestart" | -| maxRestartTime | Restart time that is announced by BIRD in the BGP graceful restart capability and that specifies how long the neighbor would wait for the BGP session to re-establish after a restart before deleting stale routes. When specified, this is configured as the graceful restart timeout when `RestartMode` is "GracefulRestart", and as the LLGR stale time when `RestartMode` is "LongLivedGracefulRestart". When not specified, the BIRD defaults are used, which are 120s for "GracefulRestart" and 3600s for "LongLivedGracefulRestart". Note: extra care should be taken when changing this configuration, as it may break networking in your cluster. | | duration | None | -| birdGatewayMode | Specifies the BIRD "gateway" mode, i.e. method for computing the immediate next hop for each received route, for peerings generated by this BGPPeer resource. Default value "Recursive" means "gateway recursive". "DirectIfDirectlyConnected" means to configure "gateway direct" when the peer is directly connected. | "Recursive", "DirectIfDirectlyConnected" | string | "Recursive" | -| numAllowedLocalASNumbers | The number of local AS numbers to allow in the AS path for received routes. This disables BGP loop prevention and should only be used if necessary. | | integer | `nil` (BIRD will default to 0 meaning no change to loop prevention behavior) | -| ttlSecurity | Enables the generalized TTL security mechanism (GTSM) which protects against spoofed packets by ignoring received packets with a smaller than expected TTL value. The provided value is the number of hops (edges) between the peers. | 0 - 255 | 8-bit integer | `nil` (results in BIRD configuration `ttl security off`) | -| filters | List of names of [BGPFilter](bgpfilter.mdx) resources to apply to this peering. | | string | | - -:::note - -The cluster-wide default local AS number used when speaking with a peer is controlled by the -[BGPConfiguration resource](bgpconfig.mdx). That value can be overridden per-node by using the `bgp` field of -the [node resource](node.mdx). - -::: - -### BGPPassword - -:::note - -BGP passwords must be 80 characters or fewer. If a password longer than that -is configured, the BGP sessions with that password will fail to be established. - -::: - -| Field | Description | Schema | -| ------------ | ------------------------------- | ----------------- | -| secretKeyRef | Get the password from a secret. | [KeyRef](#keyref) | - -### KeyRef - -KeyRef tells $[prodname] where to get a BGP password. The referenced Kubernetes -secret must be in the same namespace as the $[nodecontainer] pod. - -| Field | Description | Schema | -| ----- | ------------------------- | ------ | -| name | The name of the secret | string | -| key | The key within the secret | string | - -## Peer scopes - -BGP Peers can exist at either global or node-specific scope. A peer's scope -determines which `$[nodecontainer]`s will attempt to establish a BGP session with that peer. -If `$[nodecontainer]` has a `listenPort` set in `BGPConfiguration`, it will be used in peering. - -### Global peer - -To assign a BGP peer a global scope, omit the `node` and `nodeSelector` fields. All nodes in -the cluster will attempt to establish BGP connections with it - -### Node-specific peer - -A BGP peer can also be node-specific. When the `node` field is included, only the specified node -will peer with it. When the `nodeSelector` field is included, the nodes with labels that match that selector -will peer with it. - -## Supported operations - -| Datastore type | Create/Delete | Update | Get/List | Notes | -| --------------------- | ------------- | ------ | -------- | ----- | -| Kubernetes API server | Yes | Yes | Yes | - -## Selector - -
\ || \ | "Or": matches if and only if either `- protocol: tcp
port: 22
- protocol: udp
port: 68
- protocol: tcp
port: 179
- protocol: tcp
port: 2379
- protocol: tcp
port: 2380
- protocol: tcp
port: 5473
- protocol: tcp
port: 6443
- protocol: tcp
port: 6666
- protocol: tcp
port: 6667
- protocol: udp
port: 53
- protocol: udp
port: 67
- protocol: tcp
port: 179
- protocol: tcp
port: 2379
- protocol: tcp
port: 2380
- protocol: tcp
port: 5473
- protocol: tcp
port: 6443
- protocol: tcp
port: 6666
- protocol: tcp
port: 6667
EnabledPerNamespace,
EnabledPerNamespaceOrPerPod | string | `Disabled` | -| egressIPVXLANPort | Port to use for egress gateway VXLAN traffic. A value of `0` means "use the kernel default". | int | int | `4790` | -| egressIPVXLANVNI | Virtual network ID to use for egress gateway VXLAN traffic. A value of `0` means "use the kernel default". | int | int | `4097` | -| egressIPRoutingRulePriority | Controls the priority value to use for the egress gateway routing rule. | int | int | `100` | -| egressGatewayPollInterval | Controls the interval at which Felix will poll remote egress gateways to check their health. Only Egress Gateways with a named "health" port will be polled in this way. Egress Gateways that fail the health check will be taken our of use as if they have been deleted. | `5s`, `10s`, `1m` etc. | duration | `10s` | -| egressGatewayPollFailureCount | Controls the minimum number of poll failures before a remote Egress Gateway is considered to have failed. | int | int | `3` | -| captureDir | Controls the directory where packet capture files are stored. | string | string | `/var/log/calico/pcap` | -| captureMaxSizeBytes | Controls the maximum size in bytes for a packet capture file before rotation. | int | int | `10000000` | -| captureRotationSeconds | Controls the rotation period in seconds for a packet capture file. | int | int | `3600` | -| captureMaxFiles | Controls the maximum number rotated packet capture files. | int | int | `2` | - -\* When `dropActionOverride` is set to `LogAndDrop` or `LogAndAccept`, the `syslog` entries look something like the following. - -``` -May 18 18:42:44 ubuntu kernel: [ 1156.246182] calico-drop: IN=tunl0 OUT=cali76be879f658 MAC= SRC=192.168.128.30 DST=192.168.157.26 LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=56743 DF PROTO=TCP SPT=56248 DPT=80 WINDOW=29200 RES=0x00 SYN URGP=0 MARK=0xa000000 -``` - -\*\* Duration is denoted by the numerical amount followed by the unit of time. Valid units of time include nanoseconds (ns), microseconds (µs), milliseconds (ms), seconds (s), minutes (m), and hours (h). Units of time can also be used together e.g. `3m30s` to represent 3 minutes and 30 seconds. Any amounts of time that can be converted into larger units of time will be converted e.g. `90s` will become `1m30s`. - -
- -`genericXDPEnabled` and `xdpRefreshInterval` are only relevant when `bpfEnabled` is `false` and -`xdpEnabled` is `true`; in other words when XDP is being used to accelerate denial-of-service -prevention policies in the iptables dataplane. - -When `bpfEnabled` is `true` the "xdp" settings all have no effect; in BPF mode the implementation of -policy is always accelerated, using the best available BPF technology. - -### Health Timeout Overrides - -Felix has internal liveness and readiness watchdog timers that monitor its various loops. -If a loop fails to "check in" within the allotted timeout then Felix will report non-Ready -or non-Live on its health port (which is monitored by Kubelet in a Kubernetes system). -If Felix reports non-Live, this can result in the Pod being restarted. - -In Kubernetes, if you see the calico-node Pod readiness or liveness checks fail -intermittently, check the calico-node Pod log for a log from Felix that gives the -overall health status (the list of components will depend on which features are enabled): - -``` -+---------------------------+---------+----------------+-----------------+--------+ -| COMPONENT | TIMEOUT | LIVENESS | READINESS | DETAIL | -+---------------------------+---------+----------------+-----------------+--------+ -| CalculationGraph | 30s | reporting live | reporting ready | | -| FelixStartup | 0s | reporting live | reporting ready | | -| InternalDataplaneMainLoop | 1m30s | reporting live | reporting ready | | -+---------------------------+---------+----------------+-----------------+--------+ -``` - -If some health timeouts show as "timed out" it may help to apply an override -using the `healthTimeoutOverrides` field: - -```yaml -... -spec: - healthTimeoutOverrides: - - name: InternalDataplaneMainLoop - timeout: "5m" - - name: CalculationGraph - timeout: "1m30s" - ... -``` - -A timeout value of 0 disables the timeout. - -### ProtoPort - -| Field | Description | Accepted Values | Schema | -| -------- | -------------------- | ------------------------------------ | ------ | -| port | The exact port match | 0-65535 | int | -| protocol | The protocol match | tcp, udp, sctp | string | -| net | The CIDR match | any valid CIDR (e.g. 192.168.0.0/16) | string | - -Keep in mind that in the following example, `net: ""` and `net: "0.0.0.0/0"` are processed as the same in the policy enforcement. - -```yaml noValidation - ... -spec: - failsafeInboundHostPorts: - - net: "192.168.1.1/32" - port: 22 - protocol: tcp - - net: "" - port: 67 - protocol: udp -failsafeOutboundHostPorts: - - net: "0.0.0.0/0" - port: 67 - protocol: udp - ... -``` - -### AggregationKind - -| Value | Description | -| ----- | ---------------------------------------------------------------------------------------- | -| 0 | No aggregation | -| 1 | Aggregate all flows that share a source port on each node | -| 2 | Aggregate all flows that share source ports or are from the same ReplicaSet on each node | - -### DNSPolicyMode - -| Value | Description | -| ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| DelayDeniedPacket | Felix delays any denied packet that traversed a policy that included egress domain matches, but did not match. The packet is released after a fixed time, or after the destination IP address was programmed. | -| DelayDNSResponse | Felix delays any DNS response until related IPSets are programmed. This introduces some latency to all DNS packets (even when no IPSet programming is required), but it ensures policy hit statistics are accurate. This is the recommended setting when you are making use of staged policies or policy rule hit statistics. | -| NoDelay | Felix does not introduce any delay to the packets. DNS rules may not have been programmed by the time the first packet traverses the policy rules. Client applications need to handle reconnection attempts if initial connection attempts fail. This may be problematic for some applications or for very low DNS TTLs. | - -On Windows, or when using the eBPF dataplane, this setting is ignored and `NoDelay` is always used. - -A linux kernel version of 3.13 or greater is required to use `DelayDNSResponse`. For earlier kernel versions, this value is modified to `DelayDeniedPacket`. - -### RouteTableRange - -The `RouteTableRange` option is now deprecated in favor of [RouteTableRanges](#routetableranges). - -| Field | Description | Accepted Values | Schema | -| ----- | -------------------- | --------------- | ------ | -| min | Minimum index to use | 1-250 | int | -| max | Maximum index to use | 1-250 | int | - -### RouteTableRanges - -`RouteTableRanges` is a list of `RouteTableRange` objects: - -| Field | Description | Accepted Values | Schema | -| ----- | -------------------- | --------------- | ------ | -| min | Minimum index to use | 1 - 4294967295 | int | -| max | Maximum index to use | 1 - 4294967295 | int | - -Each item in the `RouteTableRanges` list designates a range of routing tables available to Calico. By default, Calico will use a single range of `1-250`. If a range spans Linux's reserved table range (`253-255`) then those tables are automatically excluded from the list. It's possible that other table ranges may also be reserved by third-party systems unknown to Calico. In that case, multiple ranges can be defined to target tables below and above the sensitive ranges: - -```sh - target tables 65-99, and 256-1000, skipping 100-255 -calicoctl patch felixconfig default --type=merge -p '{"spec":{"routeTableRanges": [{"min": 65, "max": 99}, {"min": 256, "max": 1000}] }} -``` - -_Note_, for performance reasons, the maximum total number of routing tables that Felix will accept is 65535 (or 2\*16). - -Specifying both the `RouteTableRange` and `RouteTableRanges` arguments is not supported and will result in an error from the api. - -### AWS IAM Role/Policy for source-destination-check configuration - -Setting `awsSrcDstCheck` to `Disable` will automatically disable source-destination-check on EC2 instances in a cluster, provided necessary IAM roles and policies are set. One of the policies assigned to IAM role of cluster nodes must contain a statement similar to the following: - -``` -{ - "Effect": "Allow", - "Action": [ - "ec2:DescribeInstances", - "ec2:ModifyNetworkInterfaceAttribute" - ], - "Resource": "*" -} -``` - -If there are no policies attached to node roles containing the above statement, attach a new policy. For example, if a node role is `test-cluster-nodeinstance-role`, click on the IAM role in AWS console. In the `Permission policies` list, add a new inline policy with the above statement to the new policy JSON definition. For detailed information, see [AWS documentation](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html?icmpid=docs_iam_console). - -For an EKS cluster, the necessary IAM role and policy is available by default. No further actions are needed. - -## Supported operations - -| Datastore type | Create | Delete | Delete (Global `default`) | Update | Get/List | Notes | -| --------------------- | ------ | ------ | ------------------------- | ------ | -------- | ----- | -| Kubernetes API server | Yes | Yes | No | Yes | Yes | | diff --git a/calico-cloud_versioned_docs/version-20-1/reference/resources/globalalert.mdx b/calico-cloud_versioned_docs/version-20-1/reference/resources/globalalert.mdx deleted file mode 100644 index 2e02283b4c..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/reference/resources/globalalert.mdx +++ /dev/null @@ -1,317 +0,0 @@ ---- -description: API for this Calico Enterprise resource. ---- - -# Global Alert - -A global alert resource represents a query that is periodically run -against data sets collected by $[prodname] whose findings are -added to the Alerts page in $[prodname] Manager. Alerts may -search for the existence of rows in a query, or when aggregated metrics -satisfy a condition. - -$[prodname] supports alerts on the following data sets: - -- [Audit logs](../../visibility/elastic/audit-overview.mdx) -- [DNS logs](../../visibility/elastic/dns/index.mdx) -- [Flow logs](../../visibility/elastic/flow/index.mdx) -- [L7 logs](../../visibility/elastic/l7/index.mdx) - -For `kubectl` [commands](https://kubernetes.io/docs/reference/kubectl/overview/), the following case-insensitive aliases -can be used to specify the resource type on the CLI: -`globalalert.projectcalico.org`, `globalalerts.projectcalico.org` and abbreviations such as -`globalalert.p` and `globalalerts.p`. - -## Sample YAML - -```yaml noValidation -apiVersion: projectcalico.org/v3 -kind: GlobalAlert -metadata: - name: sample -spec: - summary: 'Sample' - description: 'Sample ${source_namespace}/${source_name_aggr}' - severity: 100 - dataSet: flows - query: action=allow - aggregateBy: [source_namespace, source_name_aggr] - field: num_flows - metric: sum - condition: gt - threshold: 0 -``` - -## GlobalAlert definition - -### Metadata - -| Field | Description | Accepted Values | Schema | -| ----- | ----------------------- | ----------------------------------------- | ------ | -| name | The name of this alert. | Lower-case alphanumeric with optional `-` | string | - -### Spec - -| Field | Description | Type | Required | Acceptable Values | Default | -| ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------- | ----------------------------------------- | ---------------------------- | -------------------------------- | -| type | Type will dictate how the fields of the GlobalAlert will be utilized. Each `type` will have different usages and/or defaults for the other GlobalAlert fields as described in the table. | string | no | RuleBased | RuleBased | -| description | Human-readable description of the template. | string | yes | -| summary | Template for the description field in generated events. See the summary section below for more details. `description` is used if this is omitted. | string | no | -| severity | Severity of the alert for display in Manager. | int | yes | 1 - 100 | -| dataSet | Which data set to execute the alert against. | string | if `type` is `RuleBased` | audit, dns, flows, l7, vulnerability | -| period | How often the query defined will run, if `type` is `RuleBased`. | duration | no | 1h 2m 3s | 5m, 15m if `type` is `RuleBased` | -| lookback | Specifies how far back in time data is to be collected. Must exceed audit log flush interval, `dnsLogsFlushInterval`, or `flowLogsFlushInterval` as appropriate. | duration | no | 1h 2m 3s | 10m | -| query | Which data to include from the source data set. Written in a domain-specific query language. See the query section below. | string | no | -| aggregateBy | An optional list of fields to aggregate results. | string array | no | -| field | Which field to aggregate results by if using a metric other than count. | string | if metric is one of avg, max, min, or sum | -| metric | A metric to apply to aggregated results. `count` is the number of log entries matching the aggregation pattern. Others are applied only to numeric fields in the logs. | string | no | avg, max, min, sum, count | -| condition | Compare the value of the metric to the threshold using this condition. | string | if metric defined | eq, not_eq, lt, lte, gt, gte | -| threshold | A numeric value to compare the value of the metric against. | float | if metric defined | -| substitutions | An optional list of values to replace variable names in query. | List of [GlobalAlertSubstitution](#globalalertsubstitution) | no | - -### GlobalAlertSubstitution - -| Field | Description | Type | Required | -| ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | -------- | -| name | The name of the global alert substitution. It will be referenced by the variable names in query. Duplicate names are not allowed in the substitutions list. | string | yes | -| values | A list of values for this substitution. Wildcard operators asterisk (`*`) and question mark (`?`) are supported. | string array | yes | - -### Status - -| Field | Description | -| --------------- | ------------------------------------------------------------------------------------------- | -| lastUpdate | When the alert was last modified on the backend. | -| active | Whether the alert is active on the backend. | -| healthy | Whether the alert is in an error state or not. | -| lastExecuted | When the query for the alert last ran. | -| lastEvent | When the condition of the alert was last satisfied and an alert was successfully generated. | -| errorConditions | List of errors preventing operation of the updates or search. | - -## Query - -Alerts use a domain-specific query language to select which records -from the data set should be used in the alert. This could be used to -identify flows with specific features, or to select (or omit) certain -namespaces from consideration. - -The query language is composed of any number of selectors, combined -with boolean expressions (`AND`, `OR`, and `NOT`), set expressions -(`IN` and `NOTIN`) and bracketed subexpressions. These are translated -by $[prodname] to Elastic DSL queries that are executed on the backend. - -Set expressions support wildcard operators asterisk (`*`) and question mark (`?`). -The asterisk sign matches zero or more characters and the question mark matches a single character. -Set values can be embedded into the query string or reference the values -in the global alert substitution list. - -A selector consists of a key, comparator, and value. Keys and values -may be identifiers consisting of alphanumerics and underscores (`_`) -with the first character being alphabetic or an underscore, or may be -quoted strings. Values may also be integer or floating point numbers. -Comparators may be `=` (equal), `!=` (not equal), `<` (less than), -`<=` (less than or equal), `>` (greater than), or `>=` (greater than -or equal). - -Keys must be indexed fields in their corresponding data set. See the -appendix for a list of valid keys in each data set. - -Examples: - -- `query: "count > 0"` -- `query: "\"servers.ip\" = \"127.0.0.1\""` - -Selectors may be combined using `AND`, `OR`, and `NOT` boolean expressions, -`IN` and `NOTIN` set expressions, and bracketed subexpressions. - -Examples: - -- `query: "count > 100 AND client_name=mypod"` -- `query: "client_namespace = ns1 OR client_namespace = ns2"` -- `query: "count > 100 AND NOT (client_namespace = ns1 OR client_namespace = ns2)"` -- `query: "(qtype = A OR qtype = AAAA) AND rcode != NoError"` -- `query: "process_name IN {\"proc1?\", \"*proc2\"} AND source_namespace = ns1` -- `query: "qname NOTIN ${domains}"` - -## Aggregation - -Results from the query can be aggregated by any number of data fields. -Only these data fields will be included in the generated alerts, and -each unique combination of aggregations will generate a unique alert. -Careful consideration of fields for aggregation will yield the best -results. - -Some good choices for aggregations on the `flows` data set are -`[source_namespace, source_name_aggr, source_name]`, `[source_ip]`, -`[dest_namespace, dest_name_aggr, dest_name]`, and `[dest_ip]` -depending on your use case. For the `dns` data set, -`[client_namespace, client_name_aggr, client_name]` is a good choice -for an aggregation pattern. - -## Metrics and conditions - -Results from the query can be further aggregated using a metric that -is applied to a numeric field, or counts the number of rows in an -aggregation. Search hits satisfying the condition are output as -alerts. - -| Metric | Description | Applied to Field | -| ------ | ---------------------------------- | ---------------- | -| count | Counts the number of rows | No | -| min | The minimal value of the field | Yes | -| max | The maximal value of the field | Yes | -| sum | The sum of all values of the field | Yes | -| avg | The average value of the field | Yes | - -| Condition | Description | -| --------- | --------------------- | -| eq | Equals | -| not_eq | Not equals | -| lt | Less than | -| lte | Less than or equal | -| gt | Greater than | -| gte | Greater than or equal | - -Example: - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalAlert -metadata: - name: frequent-dns-responses -spec: - description: 'Monitor for NXDomain' - summary: 'Observed ${sum} NXDomain responses for ${qname}' - severity: 100 - dataSet: dns - query: rcode = NXDomain AND (rtype = A or rtype = AAAA) - aggregateBy: qname - field: count - metric: sum - condition: gte - threshold: 100 -``` - -This alert identifies non-existing DNS responses for Internet addresses -that were observed more than 100 times in the past 10 minutes. - -### Unconditional alerts - -If the `field`, `metric`, `condition`, and `threshold` fields of an -alert are left blank then the alert will trigger whenever its query -returns any data. Each hit (or aggregation pattern, if `aggregateBy` -is non-empty) returned will cause an event to be created. This should -be used **only** when the query is highly specific to avoid filling -the Alerts page and index with a large number of events. The use of -`aggregateBy` is strongly recommended to reduce the number of entries -added to the Alerts page. - -The following example would alert on incoming connections to postgres -pods from the Internet that were not denied by policy. It runs hourly -to reduce the noise. Noise could be further reduced by removing -`source_ip` from the `aggregateBy` clause at the cost of removing -`source_ip` from the generated events. - -```yaml -period: 1h -lookback: 75m -query: 'dest_labels="application=postgres" AND source_type=net AND action=allow AND proto=tcp AND dest_port=5432' -aggregateBy: [dest_namespace, dest_name, source_ip] -``` - -## Summary template - -Alerts may include a summary template to provide context for the -alerts in the $[prodname] Manager Alert user interface. Any field -in the `aggregateBy` section, or the value of the `metric` may be -substituted in the summary using a bracketed variable syntax. - -Example: - -```yaml -summary: 'Observed ${sum} NXDomain responses for ${qname}' -``` - -The `description` field is validated in the same manner. If not -provided, the `description` field is used in place of the `summary` -field. - -## Period and lookback - -The interval between alerts, and the amount of data considered by the -alert may be controlled using the `period` and `lookback` parameters -respectively. These fields are formatted as [duration](https://golang.org/pkg/time/#ParseDuration) strings. - -> A duration string is a possibly signed sequence of decimal numbers, -> each with optional fraction and a unit suffix, such as "300ms", -> "-1.5h" or "2h45m". Valid time units are "ns", "us" (or "µs"), -> "ms", "s", "m", "h". - -The default period is 5 minutes, and lookback is 10 minutes. The lookback -should always be greater than the sum of the period and the configured -`FlowLogsFlushInterval` or `DNSLogsFlushInterval` as appropriate to avoid gaps -in coverage. - -## Alert records - -With only aggregations and no metrics, the alert will generate one event -per aggregation pattern returned by the query. The record field will -contain only the aggregated fields. As before, this should be used -with specific queries. - -The addition of a metric will include the value of that metric in the -record, along with any aggregations. This, combined with queries as -necessary, will yield the best results in most cases. - -With no aggregations the alert will generate one event per record -returned by the query. The record will be included in its entirety -in the record field of the event. This should only be used with very -narrow and specific queries. - -## Templates - -$[prodname] supports the `GlobalAlertTemplate` resource type. -These are used in the $[prodname] Manager to create alerts -with prepopulated fields that can be modified to suit your needs. -The `GlobalAlertTemplate` resource is configured identically to the -`GlobalAlert` resource. $[prodname] includes some sample Alert -templates; add your own templates as needed. - -### Sample YAML - -**RuleBased GlobalAlert** - -```yaml -apiVersion: projectcalico.org/v3 -kind: GlobalAlertTemplate -metadata: - name: http.connections -spec: - description: 'HTTP connections to a target namespace' - summary: 'HTTP connections from ${source_namespace}/${source_name_aggr} to
The active packet capture file will be identified using the following schema: `{
Rotated capture files name will contain an index matching the rotation timestamp. | -| node | The hostname of the Kubernetes node the files are located on. | -| state | Determines whether a PacketCapture is capturing traffic from any interface attached to the current node. Possible values include: Capturing, Scheduled, Finished, Error, WaitingForTraffic | - -[packet capture]: /visibility/packetcapture.mdx \ No newline at end of file diff --git a/calico-cloud_versioned_docs/version-20-1/reference/resources/policyrecommendations.mdx b/calico-cloud_versioned_docs/version-20-1/reference/resources/policyrecommendations.mdx deleted file mode 100644 index 350756ac65..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/reference/resources/policyrecommendations.mdx +++ /dev/null @@ -1,56 +0,0 @@ ---- -description: API for this Calico Enterprise resource. ---- - -# Policy recommendation scope - -import Servicematch from '../../_includes/content/_servicematch.mdx'; - -import Serviceaccountmatch from '../../_includes/content/_serviceaccountmatch.mdx'; - -import Ports from '../../_includes/content/_ports.mdx'; - -import Selectors from '../../_includes/content/_selectors.mdx'; - -import Entityrule from '../../_includes/content/_entityrule.mdx'; - -import Icmp from '../../_includes/content/_icmp.mdx'; - -import Rule from '../../_includes/content/_rule.mdx'; - -The policy recommendation scope is a collection of configuration options to control [policy recommendation](../../network-policy/recommendations/policy-recommendations.mdx) in Manager UI. - -To apply changes to this resource, use the following format: - -``` -$ kubectl patch policyrecommendationscope default -p '{"spec":{"
-
-3. On the **Web Application Firewall** page, you can verify that WAF is enabled for a service by locating the service and checking that the **Status** column says **Enabled**.
-
-4. To make further changes to a service, click **Actions**, and then **Enable** or **Disable**.
-
-You have now applied WAF rule sets to your own services, and note that the traffic that goes through the selected services will be alerted but not blocked by default.
-
-#### Trigger a WAF event
-If you would like to trigger a WAF event for testing purposes, you can simulate an SQL injection attack inside your cluster by crafting a HTTP request with a query string that WAF will detect as an SQL injection attempt.
-The query string in this example has some SQL syntax embedded in the text. This is harmless and for demo purposes, but WAF will detect this pattern and create an event for this HTTP request.
-
-Run a simple curl command from any pod inside your cluster targeting a service you have selected for WAF protection e.g. from the demo app above we could attempt to send a simple HTTP request to the cartservice.
-```
- curl http://cartservice/cart?artist=0+div+1+union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A1%2C2%2Ccurrent_user
-```
-
-### Manage WAF configuration
-
-Reviewing the default rule set config:
-
-```bash
-Include @coraza.conf-recommended
-Include @crs-setup.conf.example
-Include @owasp_crs/*.conf
-
-SecRuleEngine DetectionOnly
-```
-
-The configuration file starts with importing the appropriate rule set config. We use Coraza WAF's recommended [Core Rule Set setup](https://coraza.io/docs/tutorials/coreruleset/) files:
-
-1. Coraza recommended [configuration](https://github.com/corazawaf/coraza/blob/main/coraza.conf-recommended)
-1. The rest of the [coreruleset](https://github.com/coreruleset/coreruleset) files, currently [v4.0.0-rc2](https://github.com/coreruleset/coreruleset/tree/v4.0.0-rc2)
-
-These files can be customized if desired. Add all your customizations directly under `tigera.conf`:
-
-```bash
-kubectl edit cm -n tigera-operator modsecurity-ruleset
-```
-
-After editing this ConfigMap successfully, the `modsecurity-ruleset` ConfigMap will be replaced in the `tigera-operator` namespace,
-which then triggers a rolling restart of your L7 pods. This means that the HTTP connections going through L7 pods at the time of pod termination will be (RST) reset.
-
-:::note
-
-It is important to adhere to the [Core Rule Set documentation](https://coreruleset.org/docs) on how to edit the behaviour of
- your WAF. A good place to begin at is the [Installing Core Rule Set](https://coreruleset.org/docs/deployment/install/).
-
-In many scenarios, the default example CRS configuration will be a good enough starting point. It is recommended to review the example configuration file before
-you deploy it to make sure it’s right for your environment.
-:::
-
-#### Customization options
-
-##### Set WAF to block traffic
-By default WAF will not block a request even if it has matching rule violations. The rule engine is set to `DetectionOnly`. You can configure to block traffic instead with an `HTTP 403 Forbidden` response status code when the combined matched rules scores exceed a certain threshold.
-
-1. Edit the configmap:
- ```bash
- kubectl edit cm -n tigera-operator modsecurity-ruleset
- ```
-2. Look for `SecRuleEngine DetectionOnly` and change it to `SecRuleEngine On`.
-3. Save your changes. This triggers a rolling update of the L7 pods.
-
-| Action | Description | Disruptive? |
-| ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
-| DetectionOnly | Traffic is not denied nor dropped. $[prodname] will log events. | No
-| On | Denies HTTP traffic. $[prodname] will log the event in Security Events. | Yes |
-| Off | Be cautious about using this option. Traffic is not denied, and there are no events. |No | Yes |
-
-
-##### Other basic customizations
-
-For basic customizations, it's best to add it after all the includes in `tigera.conf`. In fact, this is the reason why the `SecRuleEngine` directive and the rest of [our customizations](https://github.com/tigera/operator/blob/master/pkg/render/applicationlayer/embed/coreruleset/tigera.conf#L8-L17) are situated there.
-
-An example is adding a sampling mode. For that, the `tigera.conf` will look like this:
-
-```bash
-# Core Rule Set activation
-Include @coraza.conf-recommended
-Include @crs-setup.conf.example
-Include @owasp_crs/*.conf
-
-SecRuleEngine DetectionOnly
-
-# --- all customizations appear below this line, unless they need a specific loading order like plugins ---
-
-# --- Add sampling mode
-# Read about sampling mode here https://coreruleset.org/docs/concepts/sampling_mode/
-SecAction "id:900400,\
- phase:1,\
- pass,\
- nolog,\
- setvar:tx.sampling_percentage=50"
-```
-
-Also you can disable certain rules here:
-
-```bash
-# --- disable 'Request content type is not allowed by policy'
-SecRuleRemoveById 920420
-```
-
-Change anomaly scoring threshold:
-
-```bash
- SecAction \
- "id:900110,\
- phase:1,\
- nolog,\
- pass,\
- t:none,\
- setvar:tx.inbound_anomaly_score_threshold=25,\
- setvar:tx.outbound_anomaly_score_threshold=20"
-```
-
-Or even change rule action parameters or behavior. For example:
-
- ```bash
- # --- append to more allowed content types to request bodies
-SecAction \
- "id:900220,\
- phase:1,\
- nolog,\
- pass,\
- t:none,\
- setvar:'tx.allowed_request_content_type=|application/x-www-form-urlencoded| |multipart/form-data| |multipart/related| |text/xml| |application/xml| |application/soap+xml| |application/json| |application/cloudevents+json| |application/cloudevents-batch+json| |application/grpc|'"
-```
-
-
-##### Using Core Rule Set plugins
-
-Let's go with an example plugin: [Wordpress Rule Exclusions](https://github.com/coreruleset/wordpress-rule-exclusions-plugin/).
-
-Plugin files are the following:
-
-```
-wordpress-rule-exclusions-before.conf
-wordpress-rule-exclusions-config.conf
-```
-
-To include these files properly, structure your work directory like so:
-
-```
-tigera.conf
-wordpress-rule-exclusions-before.conf
-wordpress-rule-exclusions-config.conf
-```
-
-and then `tigera.conf` contents should be:
-
-```bash
-Include @coraza.conf-recommended
-
-Include /etc/modsecurity-ruleset/wordpress-rule-exclusions-config.conf
-Include /etc/modsecurity-ruleset/wordpress-rule-exclusions-before.conf
-
-Include @crs-setup.conf.example
-Include @owasp_crs/*.conf
-
-# if your plugin has an -after.conf, include them here
-# but wordpress rule exclusions doesn't so we're adding a comment placeholder
-# Include /etc/modsecurity-ruleset/wordpress-rule-exclusions-after.conf
-
-SecRuleEngine DetectionOnly
-```
-
-Then create and apply the configmap:
-
-```bash
-## create the configuration map itself
-kubectl create cm --dry-run=client \
- --from-file=tigera.conf \
- --from-file=wordpress-rule-exclusions-config.conf \
- --from-file=wordpress-rule-exclusions-before.conf \
- -n tigera-operator modsecurity-ruleset -o yaml > rule set.configmap.yaml
-
-## replace active configmap
-kubectl replace -f rule set.configmap.yaml
-```
-
-Read more about the order of execution for plugins here: https://coreruleset.org/docs/concepts/plugins/
-
-### View WAF events
-
-#### Security Events
-
-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 service
-
-To disable WAF on a service, use the Actions menu on the WAF board, or use the following command:
-
-```bash
-kubectl annotate svc **-** 1 iptables/eBPF rule
- 1 IP set with handful of CIDRs | -| source: nets: [ ... handful ...] | Not used | **Efficient**
- Handful of iptables/eBPF rules
- 0 IP sets | -| source: selector: foo="bar" | One network set with 2000 x /32s | **Fairly efficient**
- 1 iptables/eBPF rule
- 1 IP sets with 2000 entries | -| | Two network sets with 1000 each x /32s | **Efficient**
- 2 iptables/eBPF rules
- 2 IP set with 1000 entries | -| source:
nets: [... 2000 /32s ...]
- source:
nets: [1 x /32]
- source: nets: [1 x /32]
- ... x 2000 | Not used | **Inefficient**
Results in programming 2k iptables/eBPF rules
- 2000+ iptables/eBPF rules
- 0 IP sets | - -For more examples of network sets with policy, see: - -- Namespaced network set - - - [Secure ingress access to a microservice or application](../applications/index.mdx) - -- Global network set - - [Secure egress access from workloads to destinations outside the cluster](../applications/egress-controls.mdx) - - [Global egress access controls](../enterprise-security/global-egress.mdx) diff --git a/calico-cloud_versioned_docs/version-20-1/tutorials/calico-cloud-features/service-graph.mdx b/calico-cloud_versioned_docs/version-20-1/tutorials/calico-cloud-features/service-graph.mdx deleted file mode 100644 index 957a040b80..0000000000 --- a/calico-cloud_versioned_docs/version-20-1/tutorials/calico-cloud-features/service-graph.mdx +++ /dev/null @@ -1,132 +0,0 @@ ---- -description: Learn the basics of using Service Graph. ---- - -# Service Graph tutorial - -import ReactPlayer from 'react-player'; - -:::note - -This tutorial references the labs cluster setup that is part of the $[prodname] Trial environment. - -::: - -## What you will learn - -- The basics of Service Graph -- To visualize workload communication in the labs cluster using Service Graph -- Features of Service Graph that help you manage the scale of clusters with a large number of namespaces - -## The what and why of Service Graph - -One thing we consistently hear from DevOps engineers, SREs, and platform operators is that they struggle with getting basic visibility within their Kubernetes cluster. As more apps and microservices are deployed, and workloads are changing continuously, it becomes hard to understand how everything is working together in such a complex multi-tenant environment. Service Graph provides a "weather map" view of everything in a cluster, helping new team members ramp up quickly on how everything is communicating with each other, and an easy way to engage the right stakeholders when issues come up. Service Graph delivers a point-to-point, topographical view of how namespaces, services, and deployments are communicating with each other. - -## Quick demo - -**12-minute video** - -
and
•**View Event Logs** or **View All Logs** | | -| Compliance reports | • **View Compliance Reports** | | -| Dashboard | • **View All Logs**
and
• **View Global Network Sets** or **View Network Sets**
and (optional)
• **View Compliance Reports** | These permissions are required for the dashboard to fully populate. All users are granted limited dashboard metrics by having access to a cluster. | -| Network policies | • **View** or **Modify Policies**
or
• **View** or **Modify Global Policies**
and (optional)
• **View Audit Logs** or **View All Logs** | The **Policies** permissions apply to one or more namespaces. The **Global Policies** permissions apply to the whole cluster. These permissions are also scoped by [policy tier](../network-policy/policy-tiers/tiered-policy.mdx).
The optional **View Audit Logs** or **View All Logs** let users view the change history on the policies. | -| Service graph | • **View All Logs**
and
• **View** or **Modify Network Sets**
and (optional)
• **View** or **Modify Packet Captures** | Network sets can be restricted to a namespace or set to all namespaces to see all flows. | -| Threat feeds | • **View** or **Modify Threat Feeds** | | -| Timeline | • **View Event Logs** or **View All Logs** | | - -## Before you begin - -* You are signed in with owner or administrator permissions to the Calico Cloud Manager UI. - -## Create a custom role and add permissions - -1. Click the user icon
●
IPv4: Log from BIRD process ●
IPv6: Log from BIRD6 process |
-| `message` | text | The message contained in the log. |
-
-Once a set of BGP logs has accumulated in Elasticsearch, you can perform many interesting queries. Depending on the field that you want to query, different techniques are required. For example:
-
-- To view BGP logs only for IPv4 or IPv6, query on the `ip_version` field and sort by `logtime`
-- To see all logs from a specific node, query on the `host` field
-- To view events in the cluster, query on the `message` field
diff --git a/calico-cloud_versioned_docs/version-20-1/visibility/elastic/dns/dns-logs.mdx b/calico-cloud_versioned_docs/version-20-1/visibility/elastic/dns/dns-logs.mdx
deleted file mode 100644
index 45119345a9..0000000000
--- a/calico-cloud_versioned_docs/version-20-1/visibility/elastic/dns/dns-logs.mdx
+++ /dev/null
@@ -1,64 +0,0 @@
----
-description: Key/value pairs of DNS activity logs and how to construct queries.
----
-
-# Query DNS logs
-
-$[prodname] pushes DNS activity logs to Elasticsearch, for DNS information that is obtained from [trusted DNS servers](../../../network-policy/domain-based-policy.mdx#trusted-dns-servers). The following table
-details the key/value pairs in the JSON blob, including their
-[Elasticsearch datatype](https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-types.html).
-This information should assist you in constructing queries.
-
-| Name | Datatype | Description |
-| ------------------ | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `start_time` | date | When the collection of the log began in UNIX timestamp format. |
-| `end_time` | date | When the collection of the log concluded in UNIX timestamp format. |
-| `type` | keyword | This field contains one of the following values:●
LOG: Indicates that this is a normal DNS activity log.●
UNLOGGED: Indicates that this log is reporting DNS activity that could not be logged in detail because of [DNSLogsFilePerNodeLimit](../../../reference/resources/felixconfig.mdx#spec). |
-| `count` | long | When `type` is:●
LOG: How many DNS lookups there were, during the log collection interval, with details matching this log.●
UNLOGGED: The number of DNS responses that could not be logged in detail because of [DNSLogsFilePerNodeLimit](../../../reference/resources/felixconfig.mdx#spec). In this case none of the following fields are provided. |
-| `client_ip` | ip | The IP address of the client pod. A null value indicates aggregation. |
-| `client_name` | keyword | This field contains one of the following values:
● The name of the client pod.
● -: the name of the pod was aggregated. Check client_name_aggr for the pod name prefix.
This field contains one of the following values:
● The name of the DNS server pod.
● -: the DNS server is not a pod.
This field contains one of the following values:
● The aggregated name of the DNS server pod.
● pvt: the DNS server is not a pod. Its IP address belongs to a private subnet.
● pub: the DNS server is not a pod. Its IP address does not belong to a private subnet. It is probably on the public internet.
- `deny`: $[prodname] denied the flow. | -| `bytes_in` | long | Number of incoming bytes since the last export. | -| `bytes_out` | long | Number of outgoing bytes since the last export. | -| `dest_ip` | ip | IP address of the destination pod. A null value indicates aggregation. | -| `dest_name` | keyword | Contains one of the following values:
- Name of the destination pod.
- Name of the pod that was aggregated or the endpoint is not a pod. Check
dest_name_aggr for more information, such as the name of the pod if it was aggregated. |
-| `dest_name_aggr` | keyword | Contains one of the following values:- Aggregated name of the destination pod.
- `pvt`: endpoint is not a pod. Its IP address belongs to a private subnet.
- `pub`: endpoint is not a pod. Its IP address does not belong to a private subnet. It is probably an endpoint on the public internet. | -| `dest_namespace` | keyword | Namespace of the destination endpoint. A `-` means the endpoint is not namespaced. | -| `dest_port` | long | Destination port. Not applicable for ICMP packets. | -| `dest_service_name` | keyword | Name of the destination service. A `-` means the original destination did not correspond to a known Kubernetes service (e.g. a services ClusterIP). | -| `dest_service_namespace` | keyword | Namespace of the destination service. A `-` means the original destination did not correspond to a known Kubernetes service (e.g. a services ClusterIP). | -| `dest_service_port` | keyword | Port name of the destination service.
A `-` means :
- the original destination did not correspond to a known Kubernetes service (e.g. a services ClusterIP), or
- the destination port is aggregated.
A `*` means there are multiple service port names matching the destination port number. | -| `dest_type` | keyword | Destination endpoint type. Possible values:
- `wep`: A workload endpoint, a pod in Kubernetes.
- `ns`: A Networkset. If multiple Networksets match, then the one with the longest prefix match is chosen.
- `net`: A Network. The IP address did not fall into a known endpoint type. | -| `dest_labels` | array of keywords | Labels applied to the destination pod. A hyphen indicates aggregation. | -| `dest_domains` | array of keywords | Find all the destination domain names for use in a DNS policy by examining `dest_domains`. The field displays information on the top-level domains linked to the destination IP. Applies to flows reported from the source to destinations outside the cluster. If `flowLogsDestDomainsByClient` is disabled, having `dest_domains`: ["A"] doesn't guarantee that the flow corresponds to a connection with domain name A. The destination IP may also be linked to other domain names not yet captured by Calico. | -| `reporter` | keyword | - `src`: flow came from the pod that initiated the connection.
- `dst`: flow came from the pod that received the initial connection. | -| `num_flows` | long | Number of flows aggregated into this entry during this export interval. | -| `num_flows_completed` | long | Number of flows that were completed during the export interval. | -| `num_flows_started` | long | Number of flows that were started during the export interval. | -| `num_process_names` | long | Number of unique process names aggregated into this entry during this export interval. | -| `num_process_ids` | long | Number of unique process ids aggregated into this entry during this export interval. | -| `num_process_args` | long | Number of unique process args aggregated into this entry during this export interval. | -| `nat_outgoing_ports` | array of ints | List of [NAT](https://en.wikipedia.org/wiki/Network_address_translation) outgoing ports for the packets that were Source NAT'd in the flow | -| `packets_in` | long | Number of incoming packets since the last export. | -| `packets_out` | long | Number of outgoing packets since the last export. | -| `proto` | keyword | Protocol. | -| `policies` | array of keywords | List of policies that interacted with this flow. See [Format of the policies field](#format-of-the-policies-field). | -| `process_name` | keyword | The name of the process that initiated or received the connection or connection request. This field will have the executable path if flowLogsCollectProcessPath is enabled. A "-" indicates that the process name is not logged. A "\*" indicates that the per flow process limit has exceeded and the process names are now aggregated. | -| `process_id` | keyword | The process ID of the corresponding process (indicated by the `process_name` field) that initiated or received the connection or connection request. A "-" indicates that the process ID is not logged. A "\*" indicates that there are more than one unique process IDs for the corresponding process name. | -| `process_args` | array of strings | The arguments with which the executable was invoked. The size of the list depends on the per flow process args limit. | -| `source_ip` | ip | IP address of the source pod. A null value indicates aggregation. | -| `source_name` | keyword | Contains one of the following values:
- Name of the source pod.
- Name of the pod that was aggregated or the endpoint is not a pod. Check
source_name_aggr for more information, such as the name of the pod if it was aggregated. |
-| `source_name_aggr` | keyword | Contains one of the following values: - Aggregated name of the source pod.
- `pvt`: Endpoint is not a pod. Its IP address belongs to a private subnet.
- `pub`: the endpoint is not a pod. Its IP address does not belong to a private subnet. It is probably an endpoint on the public internet. | -| `source_namespace` | keyword | Namespace of the source endpoint. A `-` means the endpoint is not namespaced. | -| `source_port` | long | Source port. A null value indicates aggregation. | -| `source_type` | keyword | The type of source endpoint. Possible values:
- `wep`: A workload endpoint, a pod in Kubernetes.
- `ns`: A Networkset. If multiple Networksets match, then the one with the longest prefix match is chosen.
- `net`: A Network. The IP address did not fall into a known endpoint type. | -| `source_labels` | array of keywords | Labels applied to the source pod. A hyphen indicates aggregation. | -| `original_source_ips` | array of ips | List of external IP addresses collected from requests made to the cluster through an ingress resource. This field is only available if capturing external IP addresses is configured. | -| `num_original_source_ips` | long | Number of unique external IP addresses collected from requests made to the cluster through an ingress resource. This count includes the IP addresses included in the `original_source_ips` field. This field is only available if capturing external IP addresses is configured. | -| `tcp_mean_send_congestion_window` | long | Mean tcp send congestion window size. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_min_send_congestion_window` | long | Minimum tcp send congestion window size. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_mean_smooth_rtt` | long | Mean smooth RTT in micro seconds. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_max_smooth_rtt` | long | Maximum smooth RTT in micro seconds. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_mean_min_rtt` | long | Mean MinRTT in micro seconds. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_max_min_rtt` | long | Maximum MinRTT in micro seconds. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_mean_mss` | long | Mean TCP MSS. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_min_mss` | long | Minimum TCP MSS. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_total_retransmissions` | long | Total retransmitted packets. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_lost_packets` | long | Total lost packets. This field is only available if flowLogsEnableTcpStats is enabled | -| `tcp_unrecovered_to` | long | Total unrecovered timeouts. This field is only available if flowLogsEnableTcpStats is enabled | - -### Format of the policies field - -The `policies` field contains a comma-delimited list of policy rules that matched the flow. Each entry in the -list has the following format: - -``` -