--- title: Invariant sidebar_label: Overview --- import ZoomableImage from '@site/src/components/ZoomableImage'; Invariant is a network analysis platform which can validate network configurations against user-provided rules within a fast, highly scalable, cross-vendor digital twin. Its primary function is to identify network and access control issues - connectivity loss and unwanted security gaps - preventing issues with a wide variety of root causes. It can also receive scheduled scans of the live network and generate incident alerts with attached virtual traceroutes and virtual route table diffs demonstrating the issue. As a secondary function, ad-hoc rules can be tested against the digital twin, allowing Invariant to function as a powerful security research tool, or permitting instant yes/no connectivity tests and virtual traceroutes. It also supports AWS. :::info Try it now - follow the Get Started guide and tutorial to try Invariant against an example enterprise network. ::: ## How It Works Invariant does not need direct access to your network of routers and switches. The digital twin operates entirely on the network configuration files, building up simulated devices, protocol sessions, route tables, protocol-based routing and ACLs. Because it functions on configuration files only, you can use Invariant to explore detailed "what-if" scenarios through direct configuration file modification. Any passwords or secrets present in your network configuration files are deleted before Invariant can view them. Invariant provides a rich web-based user interface showing automatically laid out network maps for all current and archived network snapshots. The UI can display virtual traceroutes and is especially useful in visually understanding failures and investigating issue root causes. Individual accounts, SSO, domain-level restrictions, and other advanced security settings are available for controlling access to the UI. Invariant is designed to be easy to automate and easy to integrate in existing network change management workflows. It does not presuppose any specific release workflow. In the very simplest arrangement, you can directly collect and evaluate your network configs directly using the Python client. In more advanced configurations, you can integrate it with continuous pre-flight evaluation through Jenkins or Github Actions, automatically fetch configs using LibreNMS / Netmiko, import network names from Aerleon, Capirca, or IPAM, and send events to SIEM. Invariant also maintains searchable archives of network snapshots. You can scan these archived snapshots to determine when configuration changes were made, when incidents were introduced and resolved, and so on. Because ad-hoc rules can be tested against archived snapshot, you can perform retroactive validation to determine the behavior of the network in the past, or assess past compliance with new rules. ## Big Picture The Invariant vision is to transform network management into a more predictable, reliable, and secure process. By enabling both the primary network team and internal stakeholders to understand the full impact of changes and prevent problems through a command-line validation tool, UI, and automated validation, Invariant aims to free up network teams from firefighting, allowing them to focus on strategic initiatives and innovation. Whether you are an engineer simply opening access in an AWS Security Group or an experienced network professional performing BGP or ACL changes, Invariant can help. A mature integration of Invariant might look something like this: * Your process for making a change to the network always includes an Invariant evaluation of the planned changes. You use some kind of automation tool, like the provided Jenkins task, to automatically evaluate planned changes in Invariant. * If you support self-service network security changes, Invariant can be part of the approval process. * Virtual route table diffs are automatically generated for all network devices and all VRFs. * The Invariant Sync Agent (running in your network) regularly runs ‘SHOW RUNNING CONFIG’ or similar on network devices, removes secrets, and submits the configs for analysis. * Alerts are generated if any incident is detected. Alerts have pre-computed traceroutes attached which can be viewed in the UI. * The up-to-date network snapshot in the UI can be used by incident response, internal stakeholders investigating a service incident, compliance stakeholders, and security researchers. * Virtual network data is available as a service to internal stakeholders as a service. * Labor-intensive network security tasks, such as PCI compliance audit, ACL audit and cleanup, and incident root cause analysis can be assisted by Invariant. * Any users who use LLM tools to understand how a network config or ACL would behave can include virtual route tables and other computed information from Invariant in the LLM context to improve the accuracy and performance of the tool. You can also connect the authenticated try-rule API as a resource which LLM tools can invoke to get accurate answers to specific connectivity or security questions. ## Core Functions Invariant's capabilities are centered around its digital twin technology, rule-based validation, pre-flight checking, and detailed virtual traceroutes. ### Network Model Invariant creates a highly scalable digital twin from your network configuration files. This digital model serves as the foundation for all subsequent validation and analysis processes. The model can be hibernated in a fraction of a second, so the model consumes no standing compute resources. The model is highly effective in representing complex routing scenarios, including BGP and OSPF, as well as Network Address Translation (NAT), policy-based routing (PBR), Virtual Private Networks (VPNs), and Access Control Lists (ACLs). It is designed to scale to networks comprising thousands of devices. Invariant has been tested against real, complex production networks. We maintain a repository of example network snapshots here. Learn more about the model here. ### Validation Rules Validation rules come in two basic flavors: connectivity requirements for traffic that must always be deliverable, and security requirements for traffic that should never be deliverable. You can write them as YAML files or edit them visually in the UI. #### Example: Connectivity Requirements To write a basic rule, start by describing the kind of traffic in question: DNS connectivity to well-known public DNS providers. ```yaml protocol: TCP UDP destination-address: GOOGLE_DNS CLOUDFLARE_DNS LEVEL3_DNS destination-port: DNS ``` *Note: if you have used Aerleon or Capirca to create cross-vendor ACLs, this is the same format! You can generally copy between Aerleon ACL terms and Invariant rules. You can load your Aerleon or Capirca network and service definitions into Invariant as well.* Now turn that into an Invariant rule by wrapping it in this structure. We have set the rule type to “egress-critical-flow” which tells Invariant to confirm that key internal networks (“DMZ”, “CLIENT_VLANS”) can reach those providers (or more specifically, exit our network towards the internet in the direction of those providers). ```yaml title="invariant/policy/public-dns.yaml access-policy: - name: basic-dns-egress egress-network: DMZ CLIENT_VLANS rules: - type: egress-critical-flow protocol: TCP UDP destination-address: GOOGLE_DNS CLOUDFLARE_DNS LEVEL3_DNS destination-port: DNS ``` Above we used names to specify IP address ranges. IP addresses and CIDRs are also acceptable. ```yaml # Alternatively, IP addresses can be used directly destination-address: 8.8.8.8 8.8.4.4 1.1.1.1 1.0.0.1 209.244.0.3 209.244.0.4 # CIDR egress-network: 195.1.1.160/27 195.1.1.192/26 192.172.0.0/14 ``` Notice that we did not explicitly tell Invariant where these virtual packets should originate in our rule. Invariant performs logical start location inference to locate interfaces and devices which would realistically be able to originate the traffic based on source address. You can always directly control the start location for a rule directly, which leads to the next example: verifying the security configuration for a key VLAN. #### Example: Security Requirements In the next example we want to create a security rule which asserts that the DMZ is fully locked down to ingress traffic except what’s specified here. Invariant will search the network for counter-examples. Start with the allowed traffic: ```yaml # Traffic entering from the internet should be able to reach HTTPS services in the DMZ - start-location: EDGE_TO_INTERNET destination-port: HTTPS protocol: TCP UDP # Our internal BASTION network needs SSH, HTTP, HTTPS, and POSTGRESQL access - source-address: BASTION destination-port: SSH protocol: TCP - source-address: BASTION destination-port: HTTP HTTPS POSTGRESQL protocol: TCP UDP ``` Now turn that into an Invariant rule by wrapping it in this structure. We have set the rule type to “ingress-deny-others” which tells Invariant to search for any counter-examples to the rule, unwanted traffic which can reach the DMZ hosts. ```yaml title="invariant/policy/dmz-spec.yaml" - name: dmz-ingress-spec ingress-network: destination-address: DMZ destination-exclude: DMZ_GATEWAY rules: - type: ingress-deny-others within: - protocol: TCP UDP deny-all-except: flows: - source-address: BASTION destination-port: SSH protocol: TCP - start-location: EDGE_TO_INTERNET destination-port: HTTPS protocol: TCP UDP ``` *Note that we did something a little advanced in the ingress-network section: instead of just setting the ingress-network to DMZ, we excluded the DMZ_GATEWAY interface, with the objective of avoiding false positives for traffic deliverable directly to the gateway, because some of the enforcement is performed on the southbound outbound ACLs on the DMZ gateway.* #### Example: Vulnerability Discovery This example is from the article Discovering Network Vulnerabilities with Invariant. Suppose we are aware of a recently announced exploit related to IPP traffic over UDP. The exploit specifically applies to printers. Suppose we have deployed an ACL change to reject IPP/udp going forward. Let’s use a scan to verify that our enforcement is effective. ```yaml ingress-network: PRINT_SERVER rules: - type: ingress-deny comment: Check that CVE-2024-47176 is denied to our print server. destination-port: IPP protocol: udp ``` Invariant evaluates user rules in the context of the digital twin model. A key aspect of Invariant rule evaluation is its exhaustive nature; rules are designed to search comprehensively within potentially large ranges of network packets and origination points. This exhaustive validation provides a significantly higher degree of assurance compared to manual testing or random sampling, which are error-prone and cannot cover all possible traffic permutations. ## Deployment Model Invariant uses a client-server architecture. The client runs on your local machine or automation server (a convenience automation agent is also available for Docker or Kubernetes). If you do use the client to collect network configs, any credentials used remain on your machine and are never shared with the Invariant server. The Invariant client automatically removes all passwords or secrets present in your network configuration files before sending them to the server. Invariant runs cloud-hosted analysis servers and the UI portal at https://invariant.tech. This is where the digital twin network is created and analyzed quickly. The cloud service uses state of the art encryption and environment isolation techniques to keep your data private and secure. Invariant staff cannot view your data except through special disaster recovery accounts secured with physical tokens. If fully on-premise data retention is a requirement, please get in touch through slack or email. In any case, the analysis servers never have any access to your network and it is not possible to store network credentials there. Basic accounts can use Invariant for free with effectively no usage limits. Higher tier accounts are available which unlock SSO, access to the highest possible device count (up to hundreds or thousands of devices), and early access to upcoming preview features. --- --- title: Quick Start slug: /Get-Started/Quick-Start id: quick-start --- ## CLI Installation The Invariant CLI lets you interact with Invariant from your terminal. Use it for automation, scripting, and direct access to core features. **Installing from pip** ```bash pip install invariant-client ``` **Installing from source** ```bash git clone https://github.com/InvariantTech/client cd client pip install -e . ``` **Verify your installation** Verify the CLI is installed and working: ```bash invariant --version # client: vX.Y.Z # server: vA.B.C ``` If installed from source, use: ```bash poetry run invariant --version ``` ## Account Setup Follow this link to [Create a free account](https://prod.invariant.tech/signup). Your Invariant account will give you access to the Invariant analysis engine. ## CLI Authentication Authenticate your CLI session: ```bash invariant login ``` This prints a login URL. Open it in your browser and sign in. Never share the login code with anyone. After authentication, you'll see: ```text Logged in as your-email@example.com (tenant=your-organization-name). ``` Your session is now active. Session expiry CLI sessions expire after a period of inactivity or 24 hours. If your session expires, just run `invariant login` again. ## Running an example snapshot 1. Download the codelab solution directory and move into that directory. ```bash git clone https://github.com/InvariantTech/codelab_solution cd codelab_solution ``` 2. Log in to your Invariant account on the CLI using the `invariant login` command. ```bash invariant login ``` 3. Then invoke the `invariant run` command to upload the snapshot to Invariant ```bash invariant run ``` 4. You should see an output that looks like the following. ```bash $ invariant run Uploading snapshot... Processing... (adf11172-9f8a-4333-b7c7-f9f0ecefe8d9) Analysis complete. ╭───────────────────────┬────────╮ │ Network Information │ Rows │ ├───────────────────────┼────────┤ │ nodes │ 12 │ │ interfaces │ 94 │ │ named_structures │ 66 │ │ defined_structures │ 350 │ │ referenced_structures │ 349 │ │ unused_structures │ 5 │ │ vlan_properties │ 12 │ │ hsrp_properties │ 0 │ │ mlag_properties │ 0 │ │ ip_owners │ 51 │ │ undefined_references │ 0 │ │ vrrp_properties │ 8 │ ╰───────────────────────┴────────╯ ╭───────────────┬────────╮ │ Topology │ Rows │ ├───────────────┼────────┤ │ edges │ 42 │ │ layer_1_edges │ 0 │ │ layer_3_edges │ 42 │ │ network_map │ 1 │ ╰───────────────┴────────╯ ╭────────────────────────────┬────────╮ │ Routing │ Rows │ ├────────────────────────────┼────────┤ │ routes │ 270 │ │ bgp_process_config │ 4 │ │ bgp_peer_config │ 8 │ │ bgp_session_compatibility │ 8 │ │ bgp_session_status │ 8 │ │ bgp_edges │ 8 │ │ bgp_ribs │ 8 │ │ ospf_process_config │ 6 │ │ ospf_interface_config │ 36 │ │ ospf_area_config │ 6 │ │ ospf_session_compatibility │ 20 │ ╰────────────────────────────┴────────╯ ╭───────────────────┬────────╮ │ Setup │ Rows │ ├───────────────────┼────────┤ │ unconnected_nodes │ 0 │ │ ignored_lines │ 32 │ │ file_parse_status │ 9 │ │ parse_warnings │ 59 │ │ errors │ 0 │ ╰───────────────────┴────────╯ ╭────────────────────────┬────────╮ │ Inconsistent Traffic │ Rows │ ├────────────────────────┼────────┤ │ subnet_multipath │ 0 │ │ loopback_multipath │ 0 │ ╰────────────────────────┴────────╯ ╭──────────┬────────╮ │ Probes │ Rows │ ├──────────┼────────┤ │ probes │ 6 │ ╰──────────┴────────╯ ╭──────────────────────────────────────┬────────╮ │ Access Policy │ Rows │ ├──────────────────────────────────────┼────────┤ │ critical_flows_ok │ 1 │ │ critical_flows_violations │ 0 │ │ critical_flows_violations_unenforced │ 0 │ │ critical_flows_skipped │ 0 │ │ critical_flows_details │ 3 │ │ critical_flows_logs │ 1 │ │ policy_ok │ 3 │ │ policy_violations │ 0 │ │ policy_violations_unenforced │ 0 │ │ policy_skipped │ 0 │ │ policy_details │ 37 │ │ policy_logs │ 3 │ ╰──────────────────────────────────────┴────────╯ Run 'invariant show --snapshot adf11172-9f8a-4333-b7c7-f9f0ecefe8d9' to examine any file, or run 'export INVARIANT_SNAPSHOT=adf11172-9f8a-4333-b7c7-f9f0ecefe8d9' to skip the --snapshot argument. ``` :::info You are now ready to begin the [Tutorial](/Get-Started/Tutorial/) ::: ## Sync Agent To configure the Invariant Sync Agent, follow the steps in Automation > Invariant Sync Agent ## LLM Integration To use Invariant from or with an LLM, follow the steps in Cookbooks > LLM Integration --- --- title: llms.txt --- The Invariant documentation is available in the following LLM-friendly formats: - llms.txt - llms-full.txt If you are using an AI coding tool or LLM to work with Invariant, you can make the llms-full.txt file available as a documentation reference. You can also include it in LLM chat context. Tools like NotebookLM or Cloudflare Vectorize or AutoRAG can also make use of this file. --- --- title: Tutorial --- In this tutorial, you'll learn how to use Invariant to analyze a network snapshot and evaluate access policiy rules. You will start with a skeleton snapshot that is ready for upload but contains errors. You will start by identifying and fixing these errors in the snapshot. Once the snapshot is error-free, you will then proceed to build access policies based on the corrected snapshot. In this article: - Set up and run Invariant against the tutorial network - Learn how to spot and correct issues in network models - Attach a virtual ISP to the network - Write Invariant rules and examine virtual traceroutes to troubleshoot *20 minute read* ## Prerequisites 1. Follow the [Quick Start](/Get-Started/Quick-Start) guide to: * Install the Invariant CLI * Create a free Invariant Account * Authenticate your CLI session 2. Download the [Tutorial Network](https://github.com/InvariantTech/codelab) from Github. * You can download it from the Github website by selecting Code > Download zip . * Or use a git client. [Official git client download](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git). That's it, you are now ready to begin. :::info The completed tutorial can be found at [https://github.com/InvariantTech/codelab_solution](https://github.com/InvariantTech/codelab_solution). ::: ## Model Preparation Open the [Tutorial Network](https://github.com/InvariantTech/codelab). If you haven't already, download it using git. ```bash $ git clone https://github.com/InvariantTech/codelab.git ``` The repository contains several important directories that make up the structure of a network snapshot on disk. * `config` contains all on-premise device configurations. * `def` contains human-friendly labels for IP addresses. * `invariant` contains user-defined Invariant rules and human-friendly names for network interfaces. * `batfish` contains ISP modeling information. If you haven't already, log in to Invariant by issuing the following command and following the instructions. ```bash $ invariant login ``` This prints a login URL. Open it in your browser and sign in. Never share the login code with anyone. After authentication, you'll see: ```text Logged in as your-email@example.com (tenant=your-organization-name). ``` ### First Run Analyze the snapshot using the `invariant run` command. ```bash # Tell the CLI where to find the tutorial directory, named "codelab" $ invariant run --target path/to/codelab Uploading snapshot... Processing... (d1dff68d-7da6-4438-87d8-a12086073823) # Or just run directly from the tutorial directory $ cd codelab/ $ ls batfish configs def invariant $ invariant run ``` When the analysis completes, you will see an error about "Map Support data", followed by a list of reports files and how many rows are in each report. ```bash $ invariant run Uploading snapshot... Processing... (d1dff68d-7da6-4438-87d8-a12086073823) Analysis complete. The following steps were not completed: Evaluate Snapshot > Evaluate Snapshot > Map Support data ╭───────────────────────┬────────╮ │ Network Information │ Rows │ ├───────────────────────┼────────┤ │ nodes │ 9 │ │ interfaces │ 87 │ │ named_structures │ 54 │ │ defined_structures │ 351 │ │ referenced_structures │ 350 │ │ unused_structures │ 5 │ │ vlan_properties │ 12 │ │ hsrp_properties │ 0 │ │ mlag_properties │ 0 │ │ ip_owners │ 48 │ │ undefined_references │ 0 │ │ vrrp_properties │ 8 │ ╰───────────────────────┴────────╯ ╭───────────────┬────────╮ │ Topology │ Rows │ ├───────────────┼────────┤ │ edges │ 34 │ │ layer_1_edges │ 0 │ │ layer_3_edges │ 34 │ ╰───────────────┴────────╯ ╭────────────────────────────┬────────╮ │ Routing │ Rows │ ├────────────────────────────┼────────┤ │ routes │ 253 │ │ bgp_process_config │ 1 │ │ bgp_peer_config │ 2 │ │ bgp_session_compatibility │ 2 │ │ bgp_session_status │ 2 │ │ bgp_edges │ 0 │ │ bgp_ribs │ 1 │ │ ospf_process_config │ 6 │ │ ospf_interface_config │ 36 │ │ ospf_area_config │ 6 │ │ ospf_session_compatibility │ 20 │ ╰────────────────────────────┴────────╯ ╭───────────────────┬────────╮ │ Setup │ Rows │ ├───────────────────┼────────┤ │ unconnected_nodes │ 0 │ │ ignored_lines │ 32 │ │ file_parse_status │ 9 │ │ parse_warnings │ 59 │ │ errors │ 1 │ ╰───────────────────┴────────╯ ╭────────────────────────┬────────╮ │ Inconsistent Traffic │ Rows │ ├────────────────────────┼────────┤ │ subnet_multipath │ 0 │ │ loopback_multipath │ 0 │ ╰────────────────────────┴────────╯ ╭──────────┬────────╮ │ Probes │ Rows │ ├──────────┼────────┤ │ probes │ 3 │ ╰──────────┴────────╯ Run 'invariant show ' to examine any file. 1 error found. In Evaluate Snapshot > Map Support data: Location not found. For location 'EXTERNAL': Undefined location: 'EXTERNAL'. ``` The error message at the bottom of the output has to do with configuration we must perform for auto-mapping to appear for the tutorial network. The issue is that the tutorial network snapshot doesn't contain information about how the network is connected to the Internet or any other network (it just contains configs from devices in the tutorial network), and Invariant wants to know where the 'north' side of the network is before it will generate the map. The error suggests we fix by designating one or more interfaces with the special name 'EXTERNAL', but we can also satisfy it by connecting a virtual ISP and virtual Internet to our model! We will do so in the next section. Before we move on, let's review the data Invariant generated as part of the analysis process. The generated files are divided into multiple sections as follows. * `Network Information` provides general details about the network, including nodes and interfaces. * `Topology` contains reports describing the edges within the network. * `Routing` contains information about the calculated route tables and the processes involved in their creation. * `Setup` section contains information about errors and warnings related to model creation. * `Inconsistent Traffic` contains alternative paths between points that contain inconsistencies. * `Probes` offers quick virtual traceroutes through the model network. * `Access Policy` will appear later in the tutorial and include your deny rules and critical flows. You can examine any of these files using the `invariant show` command. ```bash # Displayes all routes across all devices and VRFs $ invariant show routes # Alternatively you can pull any file as TSV or JSON $ invariant show routes --tsv > routes.tsv $ invariant show routes --json > routes.json # Fast-JSON is just JSON but without whitespace - saves bytes $ invariant show routes --fast-json > routes.json # The 'show' command applies to the most recent snapshot uploaded from this CLI session # Alternatively you can specify the snapshot ID $ invariant show routes --snapshot d1dff68d-7da6-4438-87d8-a12086073823 ``` Complete information about the reports can be found in [the Output section](/Reference/Output/Output). ### Check For Issues In this tutorial network, we know that all network configuration files will be parsed reasonably well and all key files are present. But when you use Invariant on your own network, that might not always be the case - you might have forgotten to include the config for a key device, or maybe one of your devices is not actually supported by Invariant. Therefore, a best practice is to examine the network model and confirm that all key devices are present. Some questions you might ask in your first look of a network model could be: 1. **Are all key devices present?** Devices are called 'nodes'. ```bash $ invariant show nodes ``` 2. **Are any devices unexpectedly unconnected from the rest of the network?** Note that the analysis looks at Layer 3 (IP) connectivity. Layer 2 devices can sometimes appear disconnected as they do not explicitly participate in the Layer 3 network. ```bash $ invariant show unconnected_nodes ``` 3. **Did any files I included fail to parse?** We're looking for any file with status ERROR. It's normal for config files to have status PARTIALLY_UNRECOGNIZED - the network model safely ignores many config lines at the parser level. ```bash $ invariant show file_parse_status ``` Additional files in the **Troubleshooting** section can be helpful when diagnosing more specific issues. For example `ignored_lines` and `parse_warnings` can help you locate typos or confirm whether a config line is being ignored. `unused_structures` and `undefined_references` may point to other typos, obsolete code, or gross misconfigurations within your configs. ### Add A Virtual ISP The tutorial network snapshot doesn't contain information about how the network is connected to the Internet or any other network. It just contains configs from devices in the tutorial network. Having the model include a virtual ISP can be very useful, in fact, it is critical for the tutorial network, which relies on the ISP to define default external routes. Attaching the virtual ISP also allows Invariant to know where the 'north' side of the network, which will allow it to generate a map of your network (you can also tell Invariant where 'north' is using 'EXTERNAL' - see below). **Checking internet connectivity** We will begin by using the 'probes' tool to show that the network is indeed missing a default external route. The probes analysis runs on every network snapshot. It classifies connectivity from each node to a pre-selected list of public DNS providers. Each node can have status 'always', 'never', and 'partial'. ```bash $ invariant show probes +----+------------+-----------+---------------+------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | | target | type | comment | ignore_filters | node_outcomes | |----+------------+-----------+---------------+------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 0 | 1.1.1.1/32 | ICMP_ECHO | Default probe | True | {'asa': 'never', 'border-1': 'never', 'core-1': 'never', 'core-2': 'never', 'dc-1': 'never', 'dist-1': 'never', 'dist-2': 'never', 'dmzfw-1': 'never', 'dmzsw-1': 'never'} | | 1 | 4.2.2.2/32 | ICMP_ECHO | Default probe | True | {'asa': 'never', 'border-1': 'never', 'core-1': 'never', 'core-2': 'never', 'dc-1': 'never', 'dist-1': 'never', 'dist-2': 'never', 'dmzfw-1': 'never', 'dmzsw-1': 'never'} | | 2 | 8.8.8.8/32 | ICMP_ECHO | Default probe | True | {'asa': 'never', 'border-1': 'never', 'core-1': 'never', 'core-2': 'never', 'dc-1': 'never', 'dist-1': 'never', 'dist-2': 'never', 'dmzfw-1': 'never', 'dmzsw-1': 'never'} | +----+------------+-----------+---------------+------------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Set --json to get JSON See 'show --help' for more options ``` Without any default external route in the network model, all network devices devices appear to lack connectivity to any public DNS providers. This network expects a default route to be provided by its ISP through BGP. You will need to configure a placeholder ISP and connect it to the border-1 router. ISP settings are configured by placing a file inside the snapshot named `batfish/isp_config.json`. Start by specifying the interfaces used for ISP peering in the `borderInterfaces` section. Then, in the `ispNodeInfo` section, configure the placeholder ISPs, setting a 'role' and ASN number. The two supported roles are `TRANSIT` and `PRIVATE_BACKBONE`. The TRANSIT type will model a transit network connecting to the public internet, which is what we want here. ```json title="batfish/isp_config.json" { "borderInterfaces": [ { "borderInterface": { "hostname": "border-1", "interface": "GigabitEthernet0/1" } }, { "borderInterface": { "hostname": "border-1", "interface": "GigabitEthernet0/3" } } ], "ispNodeInfo": [ { "asn": 64501, "name": "ISP1", "role": "TRANSIT" }, { "asn": 64502, "name": "ISP2", "role": "TRANSIT" } ] } ``` With our virtual ISP configured, run `invariant run` again. When the analysis finishes, you should notice the Map Support Data error is resolved. Re-examine the probes test and you will see that connectivity to public DNS providers is now established for all network devices. Problem resolved! ```bash $ invariant show probes                   +----+------------+-----------+---------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ |    | target     | type      | comment       | ignore_filters   | node_outcomes                                                                                                                                                                                                                                           | |----+------------+-----------+---------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| |  0 | 1.1.1.1/32 | ICMP_ECHO | Default probe | True             | {'asa': 'always', 'border-1': 'always', 'core-1': 'always', 'core-2': 'always', 'dc-1': 'always', 'dist-1': 'always', 'dist-2': 'always', 'dmzfw-1': 'always', 'dmzsw-1': 'always', 'internet': 'always', 'isp_64501': 'always', 'isp_64502': 'always'} | |  1 | 4.2.2.2/32 | ICMP_ECHO | Default probe | True             | {'asa': 'always', 'border-1': 'always', 'core-1': 'always', 'core-2': 'always', 'dc-1': 'always', 'dist-1': 'always', 'dist-2': 'always', 'dmzfw-1': 'always', 'dmzsw-1': 'always', 'internet': 'always', 'isp_64501': 'always', 'isp_64502': 'always'} | |  2 | 8.8.8.8/32 | ICMP_ECHO | Default probe | True             | {'asa': 'always', 'border-1': 'always', 'core-1': 'always', 'core-2': 'always', 'dc-1': 'always', 'dist-1': 'always', 'dist-2': 'always', 'dmzfw-1': 'always', 'dmzsw-1': 'always', 'internet': 'always', 'isp_64501': 'always', 'isp_64502': 'always'} | +----+------------+-----------+---------------+------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ Set --json to get JSON See 'show --help' for more options ``` ### External Interfaces (optional) Now that we have added a virtual ISP, there is no need to set an EXTERNAL location to our network snapshot. This feature tends to be useful in sub-networks that don't connect to any ISP and are not peered with other networks. You don't need to do this to complete the tutorial, but we'll include the instructions for completeness. The EXTERNAL location should include all external-facing interfaces in your network. In the tutorial network this is `border-1` with interfaces `GigabitEthernet0/1` and `GigabitEthernet0/3`, which connect to the ISP. ```yaml title="invariant/locations/location.yaml" locations: EXTERNAL: - devices: border-1 interfaces: GigabitEthernet0/1 - devices: border-1 interfaces: GigabitEthernet0/3 ``` ## Rules Tutorial Now that we have a network snapshot in working order, let's write some rules using the Invariant rule language. Here are some key things to know before you begin. * **Structure:** * Rule files should be placed in the `invariant/policies/` directory inside the snapshot. * Network name definitions should be placed in the `def/` directory inside the snapshot. * **Format:** * Rule files are YAML files and must contain a top-level label `access-policy:` containing one or more groups of rules. * Network names definitions can be given as YAML files and must contain a top-level label `networks:`. You can also place Capirca `.net` files directly in the `def/` directory. * **Execution:** * Invariant will evaluate all rules found in the `invariant/policies/` directory every time a network snapshot is uploaded, such as by running `invariant run`. * The output `Access Policy` section will contain data about rule evaluation, including a count of how many rules failed. * You can directly execute a single rule using `invariant try-rule` which is much more efficient when adding a new rule. ### First Rules File The tutorial network contains VLANs `DATACENTER` (`172.16.50.0/24`) and `VLAN30` (`192.168.30.0/24`). Let's write a rule which verifies that SSH traffic originating on hosts in the `VLAN30` network can never reach hosts in the `DATACENTER` network. Invariant rules are always organized within a rule file according to this hierarchy: ``` access-policy > [list of rule groups] > rules > [list of rules] ``` Rules have a `type` which can be one of `ingress-deny`, `ingress-deny-others`, `ingress-critical-flow`, or the `egress-` versions of each. Our rule will use the `ingress-deny` type as we want to verify that certain traffic is never deliverable and we care about traffic ingressing into the DATACENTER network. Rule groups always have an `ingress-network` or `egress-network` depending on the type of rule contained within. This field is inherited by all rules inside the group. A rule group concerning the DATACENTER network and containing a single ingress-deny rule will start like this: ```yaml title="invariant/policies/datacenter.yaml" access-policy: - name: datacenter-security-policy ingress-network: DATACENTER rules: - type: ingress-deny ``` The ingress-deny rule needs to specify what traffic should not be permitted - here, it's SSH traffic originating in VLAN30. ```yaml source-address: VLAN30 destination-port: SSH protocol: tcp ``` It's a good practice to always add comments and team contact information in your rules, so we will add those now. Putting all the parts together, we have our first complete rule: ```yaml title="invariant/policies/datacenter.yaml" access-policy: - name: datacenter-security-policy comment: Access to the data center is controlled by this policy owner: neteng@company.com ingress-network: DATACENTER rules: - type: ingress-deny comment: VLAN30 must not be able to reach DATACENTER through SSH source-address: VLAN30 destination-port: SSH protocol: tcp ``` Let's create a new snapshot using `invariant run` containing our new rule. With the rule in place, the network must be in compliance with your rule. This rule will pass. ```bash $ invariant run Uploading snapshot... Processing... (6c334806-126c-4b63-bafe-495b39fdf995) Analysis complete. # ... skipped ╭──────────────────────────────────────┬────────╮ │ Access Policy │ Rows │ ├──────────────────────────────────────┼────────┤ │ critical_flows_ok │ 0 │ │ critical_flows_violations │ 0 │ │ critical_flows_violations_unenforced │ 0 │ │ critical_flows_skipped │ 0 │ │ critical_flows_details │ 0 │ │ critical_flows_logs │ 0 │ │ policy_ok │ 1 │ │ policy_violations │ 0 │ │ policy_violations_unenforced │ 0 │ │ policy_skipped │ 0 │ │ policy_details │ 3 │ │ policy_logs │ 1 │ ╰──────────────────────────────────────┴────────╯ Run 'invariant show ' to examine any file. ``` A new "Access Policy" section appeared in our output. The `policy_ok` data should have a single row - that represents your passing rule. If we saw a row in `policy_violations` that would indicate a failure. The `policy_detail` data is interesting. It contains three rows even though you only added a single rule. The Invariant rule engine often splits a rule into smaller parts during execution and each part produces its own detail entry. Open the `policy_ok` report. You can confirm your new rule is indeed passing. This report is easier to read using the `--json` switch as shown. Create this file using `invariant show policy_ok --json > policy_ok.json`. ```json title="policy_ok.json" [ { "index": 0, "ok": true, "skipped": false, "policy": { "comment": "Access to the data center is controlled by this policy", "egress-network": null, "enforce": null, "ingress-network": { "list": [ "DATACENTER" ], "object": null }, "name": "datacenter-security-policy", "owner": "neteng@company.com" }, "rule": { "comment": "VLAN30 must not be able to reach DATACENTER through SSH", "destination-port": [ "SSH" ], "protocol": [ "tcp" ], "source-address": [ "VLAN30" ], "type": "ingress-deny" }, "errors": [], "rule_type": "ingress-deny", "violations": 0, "checks": 6, "enforce": true } ] ``` We can see that the rule contents are reflected back in this file. The `ok` field tells us the rule passed. `enforce` tells us the rule is in effect, which is the default. It's possible to set `enforce: false` when you define a rule, which is helpful if tracking progress towards a desired network state. ### A Failing Rule Now let's expand our rule group. Our next rule will verify that VLAN40 access to DATACENTER is categorically denied. ```bash title="invariant/policies/datacenter.yaml access-policy: - name: datacenter-security-policy comment: Access to the datacenter is controlled by this policy owner: neteng@company.com ingress-network: DATACENTER rules: - type: ingress-deny comment: VLAN30 must not be able to reach DATACENTER through SSH source-address: VLAN30 destination-port: SSH protocol: tcp - type: ingress-deny comment: VLAN40 must not be able to reach DATACENTER at all. source-address: VLAN40 ``` Re-analyze the network again using `invariant run` to evaluate your new rule. Unlike the first rule, this rule will fail. The `policy_violations` data should now contain one row. When a rule fails, Invariant produces virtual traceroutes which demonstrate the issue. `policy_details` contains those traceroutes. Let's look at them to understand the problem. ```bash invariant show policy_details --json > policy_details.json ``` Search the file for `"ok": false` to locate example traceroute for the failing rule. ```json title="policy_details.json (snippet)" { "index": 2, "ok": false, "policy": { "comment": null, "egress-network": null, "enforce": null, "ingress-network": { "list": [ "DATACENTER" ], "object": null }, "name": "datacenter-security-policy", "owner": null }, "rule": { "comment": "VLAN40 must not be able to reach DATACENTER at all.", "deny-all-except": null, "destination-port": null, "protocol": null, "source-address": [ "VLAN10" ], "type": "ingress-deny", "within": null }, "resolved_as": [ { "destination_address": [ "172.16.50.0/24" ], "destination_exclude": null, "destination_node": null, "destination_port": null, "enter_interface": null, "protocol": null, "source_address": [ "192.168.10.0/24" ], "source_exclude": null, "source_interface": null, "source_port": null } ], "errors": [], "rule_type": "ingress-deny", "direction": "INGRESS_DENY", "start": "@enter(dist-2[Vlan40])", "traces": //... // ... ``` This is the beginning of the detail entry row. The `policy`, `rule`, and `ok` sections are the same as in the `policy_ok` rule we saw above. The `resolved_as` section is new - it shows you what IP addresses your network names resolved to. The `start` section is important. It tells the node and interface where the virtual traceroute originated. The content of `start` should look something like `@enter(dist-2[Vlan40])`. This expression means that the virtual packet originated outside of and entering node `dist-2` on interface `Vlan40` (`@enter` means the packet originated outside of any device). The `traces` section contains the virtual tracetoutes we want. Here is one of them: ```json title="policy_details.json (snippet)" { "action": "PERMITTED", "detail": { "arpIp": null, "filter": "vlan40-in", "filterType": "INGRESS_FILTER", "flow": { "dscp": 0, "dstIp": "172.16.50.0", "dstPort": 80, "ecn": 0, "fragmentOffset": 0, "icmpCode": null, "icmpVar": null, "ingressInterface": "Vlan40", "ingressNode": "dist-2", "ingressVrf": null, "ipProtocol": "TCP", "packetLength": 512, "srcIp": "192.168.40.253", "srcPort": 49152, "tcpFlagsAck": 0, "tcpFlagsCwr": 0, "tcpFlagsEce": 0, "tcpFlagsFin": 0, "tcpFlagsPsh": 0, "tcpFlagsRst": 0, "tcpFlagsSyn": 1, "tcpFlagsUrg": 0 }, "forwardingDetail": null, "inputInterface": "Vlan40", "inputVrf": null, "matchCriteria": null, "outputInterface": null, "resolvedNexthopIp": null, "routes": null, "sessionAction": null, "sessionScope": null, "transformation": null, "transformedFlow": null } }, { "action": "PERMITTED", "detail": { "arpIp": null, "filter": "internal-to-external", "filterType": "POST_TRANSFORMATION_INGRESS_FILTER", "flow": { "dscp": 0, "dstIp": "172.16.50.0", "dstPort": 80, "ecn": 0, "fragmentOffset": 0, "icmpCode": null, "icmpVar": null, "ingressInterface": "Vlan40", "ingressNode": "dist-2", "ingressVrf": null, "ipProtocol": "TCP", "packetLength": 512, "srcIp": "192.168.40.253", "srcPort": 49152, "tcpFlagsAck": 0, "tcpFlagsCwr": 0, "tcpFlagsEce": 0, "tcpFlagsFin": 0, "tcpFlagsPsh": 0, "tcpFlagsRst": 0, "tcpFlagsSyn": 1, "tcpFlagsUrg": 0 }, "forwardingDetail": null, "inputInterface": "INSIDE1", "inputVrf": null, "matchCriteria": null, "outputInterface": null, "resolvedNexthopIp": null, "routes": null, "sessionAction": null, "sessionScope": null, "transformation": null, "transformedFlow": null } }, ``` Unlike a live traceroute, these virtual traceroutes contain detailed information about the packet's internal progress within each node. The `flow` section describes the example packet at the moment it was processed in this step: TCP flags, fragment offset, and packet length are all shown. We can also see how the packet was handled by any firewall filters, including actions like establishing a state and forwarding the packet. You can observe if and how the packet is transformed. **Assessment** Two firewalls are letting the packets through. Fixing either firewall would close off this access and resolve the violation. Close off this traffic with the following steps: - Remove line 119 from `config/asa.cfg` - Remove line 216 from `config/dist-1.cfg` - Remove line 216 from `config/dist-2.cfg` Re-analyze the network again using `invariant run` after removing these lines to confirm that all violations are resolved. All rules should now pass. ### Deny-Others Rule Deny-others rules express exactly which traffic should be allowed in or out of a subnet within some constraints. A simple deny rule specifies what is not permitted, but a deny-others rule specifies a scope of traffic to deny and then punches holes for exempt traffic. To see this in action, create a new policy that covers VLAN40. In this policy, you will blanket deny all internal network access to VLAN40 over TCP, then carve out an exemption for traffic originating from a single host (ALICE_DESKTOP). Create the policy as follows: ```yaml title="invariant/policies/sensitive.yaml" access-policy: - name: sensitive-vlan-policy comment: Policy for the sensitive vlan. ingress-network: destination-address: VLAN40 destination-exclude: VLAN40_IF rules: - type: ingress-deny-others comment: Limit ingress to only SSH from Alice's desktop within: - protocol: tcp source-address: RFC1918 deny-all-except: flows: - comment: Internal SSH access source-address: ALICE_DESKTOP destination-port: SSH protocol: tcp ``` Re-analyze the network again using `invariant run`. Your new rule should pass. The existing network configuration permits access from Alice's desktop to VLAN40. Be aware that deny-others rules do not test whether the exempted traffic is actually deliverable. The ‘deny-all-except’ section does not assert that the exempted flows are deliverable. It asserts that flows outside the exempted traffic are never deliverable. To actually assert that a key traffic flow is deliverable, see critical flow rules in the next section. :::note You can confirm that your deny-others rule does not test whether the exempted traffic is actually deliverable by making a change that would reject traffic from ALICE_DESKTOP to VLAN40. If you delete line 64 from `config/dist-1.cfg` and `config/dist-2.cfg` and then re-run `invariant run` you should observe that there are no violations. However, if you restore the deleted line, but then modify it to allow traffic from some other IP instead of `192.168.10.98` (which is ALICE_DESKTOP), Invariant should flag this unpermitted access as a violation. ::: ### Critical Flow Rule To assert that a key traffic flow must be allowed through the network, use a critical flow rule. Critical flow rules will fail if a change to the firewall or routing partially or completely prevents delivery of the target flow. Create a policy which asserts that VLAN10 can connect to the data center. ```yaml title="invariant/policies/sensitive.yaml " access-policy: - name: vlan10-security-policy comment: Access exiting VLAN10 is controlled by this policy owner: neteng@company.com egress-network: VLAN10 rules: - type: egress-critical-flow comment: VLAN10 must be able to reach the data center. destination-address: DATACENTER destination-port: HTTPS protocol: tcp ``` Re-analyzing the network using `invariant run` will show this test passes. One row should appear in the `critical_flows_ok` report. Reports that start with `critical_flows_` will have the same schema as their `policy_` counterparts. One key difference: a passing critical flow rule will always have at least one virtual traceroute in the `critical_flows_details` report, while a deny or deny-others rule will only have a virtual traceroute when it fails. :::note A failing critical flow rule usually has one or more virtual traceroutes showing where traffic was terminated. A virtual traceroute might not be generated if the originating host has no route for the packet. ::: ## Next steps Now that we are at the end, try adding more policies and rules to the codelab and try modifying the configs to introduce violations. You may also want to try adding custom probes. Take time to experiment and learn the ins and outs of everything Invariant offers. --- --- title: Preflight Analysis Tutorial --- In this article: * Learn how to analyze planned changes using Invariant before pushing them to any network device. * Use Networks to organize snapshots. *8 minute read* ## Organizing Snapshots For Preflight Analysis Before you get started, know that network snapshots inside your account can and probably should be organized in groups called “Networks”. Each network contains a time series of snapshots, ideally representing the same network or proposed network change. This is important because Invariant can produce a network health chart per-network. You will also configure alerting rules and set security and connectivity requirements per-network. Invariant can also serve as a searchable archive of prior network snapshots. All of these functions work best when a network contains snapshots of a single site. You don’t want to mix planned or experimental network change in with your live network sync network, potentially triggering production alerts. You can name your networks whatever you like. A scheme for naming your networks could look like this: * Always include the name of the site and clarify the role of the network, e.g. `IAD-prod` might represent your production network in the IAD area. * For Networks that are regularly synced with your live network environment, append `-synced` to the network name. * For Networks that track the 'golden' or intended configuration of the network, append `-golden` to the network name. * For Networks that contain proposed changes, start with the baseline network you intend to use, then add `-proposed-` and a unique name for the proposal, e.g.`IAD-prod-proposed-06-25-maintenance` or `IAD-prod-proposed-JIRA-803`. * For Networks containing changes that aren’t necessarily intended to go live, use `-experimental`, e.g. `IAD-prod-experimental-JIRA-894`. ## Selecting A Baseline Snapshot To get started with a differential change analysis, you will need to do the following: - Choose a name for the network you will use for this analysis. - Identify the network snapshot to use as your baseline. - Collect the network configuration files for that baseline version. - Retrieve the snapshot UUID from the Invariant analysis of that snapshot. If the baseline version hasn’t been analyzed by Invariant yet, analyze it now and note the UUID. **Choose a name for the network you will use for this analysis.** As suggested above, because we are building on baseline network `IAD-prod`, we can name our planned change network `IAD-prod-proposed-JIRA-803`, where `JIRA-803` might be a ticket tracking the work we hope to address with our change. **Identify the network snapshot to use as your baseline.** For our example we are going to start by fetching a new snapshot of the `IAD-prod` network to use as our baseline. We will fetch these configs, store them locally, and upload them for initial analysis, making note of the new snapshot UUID. Then we will make our edits to the local network config files. **Collect the network config files for that baseline version.** We can use the CLI in “fetch” mode to collect the latest network config files using the same fetcher config used to sync with production. Run `invariant fetch`. **Get the snapshot UUID of the Invariant analysis of that snapshot.** We can use `invariant run --network IAD-prod-proposed-JIRA-803` to analyze the snapshot we just fetched from the live network and place it in our IAD-prod-proposed-JIRA-803 network. We will note the UUID of this new snapshot - b1dc9602-d62d-4cd1-aa55-21293c0e826d . ## Edit Network Configuration Files Directly *Disaster Averted* Suppose our task is to decommission an IPSec tunnel which we believe is not in use. However, we will responsibly verify our change using Invariant first. Naturally, we will discover that we are mistaken, as the IPSec tunnels we think are unused are actually the ones that connect our on-premise enterprise network to our AWS infrastructure. This will certainly cause an outage in our network if deployed, but our analysis will reveal the failure and provide very detailed information about the extent of the potential outage if we were to deploy it. We will directly modify the network config file for border-1.cfg to show that we intend to shut down interfaces Tunnel1 and Tunnel2 on device border-1 . ```diff --- a/p/demo/private/enterprise_quick/configs/border-1.cfg +++ b/p/demo/private/enterprise_quick/configs/border-1.cfg @@ -139,6 +139,7 @@ crypto ipsec profile ipsec-vpn-0dc7abdb974ff8a69-1 ! interface Tunnel1 + shutdown ip address 169.254.25.162 255.255.255.252 ip tcp adjust-mss 1379 tunnel source 197.10.10.2 @@ -148,6 +149,7 @@ interface Tunnel1 ip virtual-reassembly ! interface Tunnel2 + shutdown ip address 169.254.172.2 255.255.255.252 ip tcp adjust-mss 1379 tunnel source 197.10.10.2 ``` To see the impact of our change, we start by re-running the analysis run `invariant run`. This will generate route tables and other network model data describing the state of the digital twin network with this change applied. It will also evaluate all Invariant rules in the snapshot, and if any rules are violated by the change, it will generate virtual traceroutes demonstrating the issue. We will set the --condensed flag which causes the terminal to simply report on whether there were rule failures while still generating all network data files. ```bash $ invariant run --network IAD-prod-proposed-JIRA-803 --condensed snapshot: d457e2da-9416-42d1-b606-6d3c36209878 outcome: Rule violations found ``` **At this point we know there are rule violations found**. Invariant has created virtual traceroutes which we could investigate. However, given that we just shut down an IPSec tunnel and Invariant is reporting connectivity loss, we can safely assume that our change had some kind of impact on the route tables or protocol establishment, so a good place to start is diffing the network model details between our change and the baseline snapshot. To compare the network models, create three directories: “baseline/” “current/” and “output_diffs/” ```bash mkdir -p current baseline output_diffs ``` :::note This logic may be migrated into the Invariant application in a future release. ::: Then, edit the BASELINE_SNAPSHOT value below, and run this script. Optionally, you can [install the diff tool “dyff”](https://github.com/homeport/dyff) and this script will use it. ```bash # Put the baseline snapshot UUID here: export BASELINE_SNAPSHOT="b1dc9602-d62d-4cd1-aa55-21293c0e826d" export INVARIANT_REPORTS="nodes interfaces routes edges ipsec_session_status ipsec_edges bgp_process_config bgp_peer_config bgp_session_compatibility bgp_session_status bgp_edges bgp_ribs ospf_process_config ospf_interface_config ospf_area_config ospf_session_compatibility isis_edges eigrp_edges loops multipath file_parse_status ignored_lines parse_warnings errors probes" echo "Downloading files for current snapshot into 'current' directory..." for report_type in $INVARIANT_REPORTS; do echo "Fetching current ${report_type}.json..." invariant show "$report_type" --json > "current/${report_type}.json" done echo "Downloading files for BASELINE snapshot ($BASELINE_SNAPSHOT) into 'baseline' directory..." for report_type in $INVARIANT_REPORTS; do echo "Fetching baseline ${report_type}.json..." invariant show "$report_type" --snapshot "$BASELINE_SNAPSHOT" --json > "baseline/${report_type}.json" done echo "Performing diff between 'baseline/' and 'current/' directories..." diff -urN "baseline/" "current/" > "output_diffs/0_invariant_data.diff" || true if [ -s "output_diffs/0_invariant_data.diff" ]; then if command -v dyff &> /dev/null; then echo "dyff command found. Generating dyff summary..." dyff between --color off -b "baseline/" "current/" > "output_diffs/1_invariant_diff_summary.txt" || true if [ -s "output_diffs/1_invariant_diff_summary.txt" ]; then echo "dyff summary saved to output_diffs/1_invariant_diff_summary.txt" echo "--- dyff Summary ---" cat "output_diffs/1_invariant_diff_summary.txt" echo "--- End dyff Summary ---" else echo "dyff ran but produced no output." fi else echo "Differences found. Full diff saved to output_diffs/0_invariant_data.diff" head -n 40 "output_diffs/0_invariant_data.diff" echo "" fi else echo "No differences found between 'baseline' and 'current' directories." fi echo "" echo "Baseline files are in: baseline/" echo "Current files are in: current/" if [ -s "output_diffs/0_invariant_data.diff" ]; then echo "Diff outputs (if any) are in: output_diffs/" fi echo "Done." ``` ## Understanding The Issue With the information from the network model diffs we can start to piece together the mechanics of the averted outage step by step. A great place to start is by looking at the difference between RIBs. We can see that several key routes would be lost with this change: The border-1 device loses key /16 routes to the AWS network, which would have carried traffic over the transit gateway IPSec tunnels. The border-1 device also loses /30 routes established by the IPSec tunnel. Normally, BGP is established over these links, which allows AWS to advertise those /16 networks. Note that next-hop on the /16 routes (in the golden branch) were set to 169.254.25.161 and 169.254.172.1, which would have been the AWS side of the IPSec tunnel. ``` (root level) (routes.json) - eight list entries removed: - Admin_Distance: 1 Metric: 0 Network: 10.20.0.0/16 Next_Hop: type: ip interface: null ip: 169.254.25.161 Next_Hop_IP: 169.254.25.161 Next_Hop_Interface: dynamic Next_Hop_str: "ip 169.254.25.161" Node: border-1 Protocol: static Tag: null VRF: default - Admin_Distance: 1 Metric: 0 Network: 10.20.0.0/16 Next_Hop: type: ip interface: null ip: 169.254.172.1 Next_Hop_IP: 169.254.172.1 Next_Hop_Interface: dynamic Next_Hop_str: "ip 169.254.172.1" Node: border-1 Protocol: static Tag: null VRF: default - Admin_Distance: 1 Metric: 0 Network: 10.30.0.0/16 Next_Hop: type: ip interface: null ip: 169.254.25.161 Next_Hop_IP: 169.254.25.161 Next_Hop_Interface: dynamic Next_Hop_str: "ip 169.254.25.161" Node: border-1 Protocol: static Tag: null VRF: default - Admin_Distance: 1 Metric: 0 Network: 10.30.0.0/16 Next_Hop: type: ip interface: null ip: 169.254.172.1 Next_Hop_IP: 169.254.172.1 Next_Hop_Interface: dynamic Next_Hop_str: "ip 169.254.172.1" Node: border-1 Protocol: static Tag: null VRF: default - Admin_Distance: 0 Metric: 0 Network: 169.254.25.160/30 Next_Hop: type: interface interface: Tunnel1 ip: null Next_Hop_IP: AUTO/NONE(-1l) Next_Hop_Interface: Tunnel1 Next_Hop_str: "interface Tunnel1" Node: border-1 Protocol: connected Tag: null VRF: default - Admin_Distance: 0 Metric: 0 Network: 169.254.25.162/32 Next_Hop: type: interface interface: Tunnel1 ip: null Next_Hop_IP: AUTO/NONE(-1l) Next_Hop_Interface: Tunnel1 Next_Hop_str: "interface Tunnel1" Node: border-1 Protocol: local Tag: null VRF: default - Admin_Distance: 0 Metric: 0 Network: 169.254.172.0/30 Next_Hop: type: interface interface: Tunnel2 ip: null Next_Hop_IP: AUTO/NONE(-1l) Next_Hop_Interface: Tunnel2 Next_Hop_str: "interface Tunnel2" Node: border-1 Protocol: connected Tag: null VRF: default - Admin_Distance: 0 Metric: 0 Network: 169.254.172.2/32 Next_Hop: type: interface interface: Tunnel2 ip: null Next_Hop_IP: AUTO/NONE(-1l) Next_Hop_Interface: Tunnel2 Next_Hop_str: "interface Tunnel2" Node: border-1 Protocol: local Tag: null VRF: default ``` Key BGP sessions between AWS and border-1 cannot be established, failing with UNKNOWN_REMOTE. ``` (root level) (bgp_session_compatibility.json) - two list entries removed: + two list entries added: - Address_Families: [] - Address_Families: [] Configured_Status: HALF_OPEN Configured_Status: UNKNOWN_REMOTE Local_AS: 64512 Local_AS: 64512 Local_IP: 169.254.25.161 Local_IP: 169.254.25.161 Local_Interface: null Local_Interface: null Local_Interface_str: None Local_Interface_str: None Node: tgw-06b348adabd13452d Node: tgw-06b348adabd13452d Remote_AS: 64500 Remote_AS: 64500 Remote_IP: 169.254.25.162 Remote_IP: 169.254.25.162 Remote_Interface: null Remote_Interface: null Remote_Interface_str: None Remote_Interface_str: None Remote_Node: null Remote_Node: null Session_Type: EBGP_SINGLEHOP Session_Type: EBGP_SINGLEHOP VRF: vrf-tgw-rtb-00e37bc5142347b03 VRF: vrf-tgw-rtb-00e37bc5142347b03 - Address_Families: [] - Address_Families: [] Configured_Status: HALF_OPEN Configured_Status: UNKNOWN_REMOTE Local_AS: 64512 Local_AS: 64512 Local_IP: 169.254.172.1 Local_IP: 169.254.172.1 Local_Interface: null Local_Interface: null Local_Interface_str: None Local_Interface_str: None Node: tgw-06b348adabd13452d Node: tgw-06b348adabd13452d Remote_AS: 64500 Remote_AS: 64500 Remote_IP: 169.254.172.2 Remote_IP: 169.254.172.2 Remote_Interface: null Remote_Interface: null Remote_Interface_str: None Remote_Interface_str: None Remote_Node: null Remote_Node: null Session_Type: EBGP_SINGLEHOP Session_Type: EBGP_SINGLEHOP VRF: vrf-tgw-rtb-00e37bc5142347b03 VRF: vrf-tgw-rtb-00e37bc5142347b03 ``` Using this deep network behavior comparison data, we can confirm that the mechanics of the incident were as follows: the Tunnel1, Tunnel2 interfaces were shut down. All connectivity to the AWS Transit Gateway was lost. Key /16 networks would have been advertised by AWS through BGP over the IPSec tunnels, but were no longer advertised. Without having examined the virtual traceroutes, we can already conclude that this change is not safe and these Tunnel interfaces are not ready to be decommissioned. --- --- title: Jenkins Automation Demo sidebar_label: Jenkins Automation Demo slug: /Automation --- import ZoomableImage from '@site/src/components/ZoomableImage'; ## In This Demo * Integrate Invariant with Jenkins to test preflight network changes in an offline digital twin environment. * Rapidly triage and identify the root cause of incidents using deep network drift detection in Invariant. * Examine routing tables (RIBs), protocol sessions (BGP, IPSec), and other information in the network model after the proposed network configuration change is applied. * Demonstrate network-as-code using native network config language. ## Scenario This demo involves a network team maintaining a code branch, "golden_branch", which holds network configs representing the current state of the production network as planned. To plan or explore a potential change to the network, the network team can directly modify network configs on a separate branch. In this example, the branch is named "change_proposal", but in reality you would be more specific, and might cite a ticket number. Jenkins is configured to pick up new changes and "build" them, where building means analyzing the network snapshot (with changes) for rule violations and generally looking for changes across all aspects of the network: routing tables (RIBs), protocol sessions (BGP, IPSec), etc. We will now introduce a problematic change to demonstrate the tool. ## Demonstration: Disaster Averted We’re going to shut down the IPSec tunnels that connect our on-premise enterprise network to our AWS infrastructure. This will certainly cause an outage in our network, and our Jenkins build will fail and provide very detailed information about the extent of the outage. We start by spelling out the change we plan to make. We will directly modify the network config file for border-1.cfg to show that we intend to shut down interfaces Tunnel1 and Tunnel2 on device border-1 . ```diff --- a/p/demo/private/enterprise_quick/configs/border-1.cfg +++ b/p/demo/private/enterprise_quick/configs/border-1.cfg @@ -139,6 +139,7 @@ crypto ipsec profile ipsec-vpn-0dc7abdb974ff8a69-1 ! interface Tunnel1 + shutdown ip address 169.254.25.162 255.255.255.252 ip tcp adjust-mss 1379 tunnel source 197.10.10.2 @@ -148,6 +149,7 @@ interface Tunnel1 ip virtual-reassembly ! interface Tunnel2 + shutdown ip address 169.254.172.2 255.255.255.252 ip tcp adjust-mss 1379 tunnel source 197.10.10.2 ``` We can commit that change in git as a new branch, “change_proposal”, and push it to the repo. The Jenkins task will pick up the change and run a build automatically. Jenkins has already scanned the baseline “golden network state” where we stored our configs the last time we updated the network. The green checkmark circle icon near the branch name (“golden_branch”) tells us this branch is passing all Invariant rule checks. Now let’s look at our change_proposal branch. The red “X” circle icon tells us that this branch is not passing Invariant rule checks. Let’s drill down to the specific build (#1). From here we will examine the console output. The console does show that the task used Invariant to analyze the network snapshot, and Invariant reported “outcome: Rule violations found”. That is what we expected, but now let’s go deeper and find out which rules failed, and why. Back on to the specific build page (#1) there is a link for “Build Artifacts”. Artifacts are files produced by our build, which include detailed information about the network, the Invariant rule failure details, and a comparison against the golden branch. While the invariant_rule_failure_data folder contains the raw JSON of all rule failures, traceroutes, and so on, it might be faster to just pop into the Invariant UI and explore from there. Here is what our golden_branch looks like in the Invariant UI. We can see on the left that 2/2 rules are passing. We also should notice how there is a layer 3 connection established between our border-1 device and our AWS transit gateway (tgw). Again looking at our golden_branch, we can see that our first Invariant rule tests connectivity to our AWS infrastructure. The UI shows the paths that traffic can take, and we can see that the IPSec tunnel is critical for this connectivity requirement. Now we can look at our change proposal in the Invariant UI. It’s apparent that two things are different: both rules are failing, and there is no longer a connection between border-1 and the AWS transit gateway. Inspecting the failing connectivity rule, we can see that the rule tries to reach a private IP address in 10.20.0.0/16 (AWS VPC). However, without the IPSec tunnel, and with no route for that /16, the test traffic hits the default route on border-1, exits the network, and is rejected by the ISP. At this point we already have a pretty good sense of the issue. You should probably not deploy this change if losing connectivity to your AWS infrastructure is not acceptable. Had this change been deployed to the production network, the information explored thus far may already warrant reverting it. Perhaps you only wanted to see what would happen if you applied a change to the network, which is valid. Although this failure was designed to be obvious, it isn't always fully clear how a network change impacts the network’s behavior. Network configuration is famously non-obvious. Let’s go deeper into the tool to understand exactly what went wrong. ## Root Cause Invariant gives you tools to perform a root cause analysis of a network issue. To do this we will return to the Artifacts folder and examine the network data comparison to understand what went wrong. We will look in the network diff folder. It contains two files, a .diff file and a .txt file. Both contain complete comparison details between our branch (change_proposal) and the golden branch (golden_branch). We will look at the summary.txt file (it is easier to read). We can start to piece together the mechanics of the outage step by step. A great place to start is by looking at the difference between RIBs. We can see that several key routes would be lost with this change: The border-1 device loses key /16 routes to the AWS network, which would have carried traffic over the transit gateway IPSec tunnels. The border-1 device also loses /30 routes established by the IPSec tunnel. Normally, BGP is established over these links, which allows AWS to advertise those /16 networks. Note that next-hop on the /16 routes (in the golden branch) were set to 169.254.25.161 and 169.254.172.1, which would have been the AWS side of the IPSec tunnel. ``` (root level) (routes.json) - eight list entries removed: - Admin_Distance: 1 Metric: 0 Network: 10.20.0.0/16 Next_Hop: type: ip interface: null ip: 169.254.25.161 Next_Hop_IP: 169.254.25.161 Next_Hop_Interface: dynamic Next_Hop_str: "ip 169.254.25.161" Node: border-1 Protocol: static Tag: null VRF: default - Admin_Distance: 1 Metric: 0 Network: 10.20.0.0/16 Next_Hop: type: ip interface: null ip: 169.254.172.1 Next_Hop_IP: 169.254.172.1 Next_Hop_Interface: dynamic Next_Hop_str: "ip 169.254.172.1" Node: border-1 Protocol: static Tag: null VRF: default - Admin_Distance: 1 Metric: 0 Network: 10.30.0.0/16 Next_Hop: type: ip interface: null ip: 169.254.25.161 Next_Hop_IP: 169.254.25.161 Next_Hop_Interface: dynamic Next_Hop_str: "ip 169.254.25.161" Node: border-1 Protocol: static Tag: null VRF: default - Admin_Distance: 1 Metric: 0 Network: 10.30.0.0/16 Next_Hop: type: ip interface: null ip: 169.254.172.1 Next_Hop_IP: 169.254.172.1 Next_Hop_Interface: dynamic Next_Hop_str: "ip 169.254.172.1" Node: border-1 Protocol: static Tag: null VRF: default - Admin_Distance: 0 Metric: 0 Network: 169.254.25.160/30 Next_Hop: type: interface interface: Tunnel1 ip: null Next_Hop_IP: AUTO/NONE(-1l) Next_Hop_Interface: Tunnel1 Next_Hop_str: "interface Tunnel1" Node: border-1 Protocol: connected Tag: null VRF: default - Admin_Distance: 0 Metric: 0 Network: 169.254.25.162/32 Next_Hop: type: interface interface: Tunnel1 ip: null Next_Hop_IP: AUTO/NONE(-1l) Next_Hop_Interface: Tunnel1 Next_Hop_str: "interface Tunnel1" Node: border-1 Protocol: local Tag: null VRF: default - Admin_Distance: 0 Metric: 0 Network: 169.254.172.0/30 Next_Hop: type: interface interface: Tunnel2 ip: null Next_Hop_IP: AUTO/NONE(-1l) Next_Hop_Interface: Tunnel2 Next_Hop_str: "interface Tunnel2" Node: border-1 Protocol: connected Tag: null VRF: default - Admin_Distance: 0 Metric: 0 Network: 169.254.172.2/32 Next_Hop: type: interface interface: Tunnel2 ip: null Next_Hop_IP: AUTO/NONE(-1l) Next_Hop_Interface: Tunnel2 Next_Hop_str: "interface Tunnel2" Node: border-1 Protocol: local Tag: null VRF: default ``` We can see that interfaces Tunnel1 and Tunnel2 were shut down administratively by the “shutdown” commands. ``` border-1[Tunnel1].Active (interfaces.json) ± value change - true + false border-1[Tunnel1].Admin_Up (interfaces.json) ± value change - true + false border-1[Tunnel1].Inactive_Reason (interfaces.json) ± value change - + Administratively down border-1[Tunnel2].Active (interfaces.json) ± value change - true + false border-1[Tunnel2].Admin_Up (interfaces.json) ± value change - true + false border-1[Tunnel2].Inactive_Reason (interfaces.json) ± value change - + Administratively down ``` Next, we can see that IPSec sessions would not be established between the Tunnel interfaces and AWS. ``` (root level) (ipsec_edges.json) - four list entries removed: - Remote_Source_Interface: hostname: tgw-06b348adabd13452d interface: external-vpn-01c45673532d3e33e-2 Remote_Source_Interface_str: tgw-06b348adabd13452d[external-vpn-01c45673532d3e33e-2] Remote_Tunnel_Interface: hostname: tgw-06b348adabd13452d interface: vpn-vpn-01c45673532d3e33e-2 Remote_Tunnel_Interface_str: tgw-06b348adabd13452d[vpn-vpn-01c45673532d3e33e-2] Source_Interface: hostname: border-1 interface: GigabitEthernet0/3 Source_Interface_str: border-1[GigabitEthernet0/3] Tunnel_Interface: hostname: border-1 interface: Tunnel2 Tunnel_Interface_str: border-1[Tunnel2] - Remote_Source_Interface: hostname: border-1 interface: GigabitEthernet0/3 Remote_Source_Interface_str: border-1[GigabitEthernet0/3] Remote_Tunnel_Interface: hostname: border-1 interface: Tunnel1 Remote_Tunnel_Interface_str: border-1[Tunnel1] Source_Interface: hostname: tgw-06b348adabd13452d interface: external-vpn-01c45673532d3e33e-1 Source_Interface_str: tgw-06b348adabd13452d[external-vpn-01c45673532d3e33e-1] Tunnel_Interface: hostname: tgw-06b348adabd13452d interface: vpn-vpn-01c45673532d3e33e-1 Tunnel_Interface_str: tgw-06b348adabd13452d[vpn-vpn-01c45673532d3e33e-1] - Remote_Source_Interface: hostname: border-1 interface: GigabitEthernet0/3 Remote_Source_Interface_str: border-1[GigabitEthernet0/3] Remote_Tunnel_Interface: hostname: border-1 interface: Tunnel2 Remote_Tunnel_Interface_str: border-1[Tunnel2] Source_Interface: hostname: tgw-06b348adabd13452d interface: external-vpn-01c45673532d3e33e-2 Source_Interface_str: tgw-06b348adabd13452d[external-vpn-01c45673532d3e33e-2] Tunnel_Interface: hostname: tgw-06b348adabd13452d interface: vpn-vpn-01c45673532d3e33e-2 Tunnel_Interface_str: tgw-06b348adabd13452d[vpn-vpn-01c45673532d3e33e-2] - Remote_Source_Interface: hostname: tgw-06b348adabd13452d interface: external-vpn-01c45673532d3e33e-1 Remote_Source_Interface_str: tgw-06b348adabd13452d[external-vpn-01c45673532d3e33e-1] Remote_Tunnel_Interface: hostname: tgw-06b348adabd13452d interface: vpn-vpn-01c45673532d3e33e-1 Remote_Tunnel_Interface_str: tgw-06b348adabd13452d[vpn-vpn-01c45673532d3e33e-1] Source_Interface: hostname: border-1 interface: GigabitEthernet0/3 Source_Interface_str: border-1[GigabitEthernet0/3] Tunnel_Interface: hostname: border-1 interface: Tunnel1 Tunnel_Interface_str: border-1[Tunnel1] ``` Key BGP sessions between AWS and border-1 cannot be established, failing with UNKNOWN_REMOTE. ``` (root level) (bgp_session_compatibility.json) - two list entries removed: + two list entries added: - Address_Families: [] - Address_Families: [] Configured_Status: HALF_OPEN Configured_Status: UNKNOWN_REMOTE Local_AS: 64512 Local_AS: 64512 Local_IP: 169.254.25.161 Local_IP: 169.254.25.161 Local_Interface: null Local_Interface: null Local_Interface_str: None Local_Interface_str: None Node: tgw-06b348adabd13452d Node: tgw-06b348adabd13452d Remote_AS: 64500 Remote_AS: 64500 Remote_IP: 169.254.25.162 Remote_IP: 169.254.25.162 Remote_Interface: null Remote_Interface: null Remote_Interface_str: None Remote_Interface_str: None Remote_Node: null Remote_Node: null Session_Type: EBGP_SINGLEHOP Session_Type: EBGP_SINGLEHOP VRF: vrf-tgw-rtb-00e37bc5142347b03 VRF: vrf-tgw-rtb-00e37bc5142347b03 - Address_Families: [] - Address_Families: [] Configured_Status: HALF_OPEN Configured_Status: UNKNOWN_REMOTE Local_AS: 64512 Local_AS: 64512 Local_IP: 169.254.172.1 Local_IP: 169.254.172.1 Local_Interface: null Local_Interface: null Local_Interface_str: None Local_Interface_str: None Node: tgw-06b348adabd13452d Node: tgw-06b348adabd13452d Remote_AS: 64500 Remote_AS: 64500 Remote_IP: 169.254.172.2 Remote_IP: 169.254.172.2 Remote_Interface: null Remote_Interface: null Remote_Interface_str: None Remote_Interface_str: None Remote_Node: null Remote_Node: null Session_Type: EBGP_SINGLEHOP Session_Type: EBGP_SINGLEHOP VRF: vrf-tgw-rtb-00e37bc5142347b03 VRF: vrf-tgw-rtb-00e37bc5142347b03 ``` Using this deep network behavior comparison data, we can confirm that the mechanics of the incident were as follows: The Tunnel1, Tunnel2 interfaces were shut down. All connectivity to the AWS Transit Gateway was lost. Key /16 networks would have been advertised by AWS through BGP over the IPSec tunnels, but were no longer advertised. ## Invariant Basics This section walks through how the Jenkins script works. We'll start by introducing the functions of Invariant used by the script, then walk through the key parts of the script. ### Setup To connect to Invariant, we need the Invariant CLI, a Python CLI tool. The latest version can be installed using: ```bash $ pip install invariant-client ``` Check the current installed version and the server connection using: ```bash $ invariant --version client: v1.10.3 server: v1.9.1 ``` Invariant provides a tool for compiling a snapshot of your network. It can fetch information from Oxidized, directly from network devices (LibreNMS), and from your AWS REST API (Boto3). In this demo, that tool was already used to capture a network snapshot. We are now using that snapshot as a basis to test planned network changes before they go live (preflight). You can examine the structure of the network snapshot here: (link). !! Key point: compiling a network snapshot is always performed by you on your local device using local credentials; the Invariant server has no access to your network or credentials. ### Evaluate the network in the digital twin environment Use the “invariant run” CLI command to evaluate the network in a digital twin environment. ```bash $ invariant run --target demo/enterprise_quick/ --condensed ``` Let’s explain the parts: “Invariant run” This command sends the network snapshot at the directory specified by --target to Invariant. Invariant will handle the heavy lifting of securely creating and destroying the digital twin network, understanding and processing the connectivity and access policy requirements, and compiling derived model information in a useful and diff-able format. `--target demo/enterprise_quick/` This is the local directory where the network snapshot exists. `--condensed` This requests ‘condensed output’ which summarizes the outcome in a single line (pass / fail / error). ### Fetch and diff deep network model attributes Use the “invariant show” CLI command to fetch deep analysis reports. This includes interface details, BGP session status, RIBs on all devices, IPSec status, and more. ```bash $ invariant show bgp_session_status --snapshot --json > bgp_session_status.json ``` In the demo, we will loop over a list of well-known analysis reports. Once fetched, we can attach them to the Jenkins run as artifacts, and diff them against the prior state of the network or a “golden” state. ## Automating with Jenkins In our scenario, we want our network engineers to commit planned network changes to the ‘golden_branch’ branch. Jenkins will watch this branch for changes and kick off a task running Invariant tests and comparing the state of the ‘golden_branch’ branch to the state of the ‘release’ branch. To accomplish this we must package our automation script as a Jenkinsfile. The full text of the file can be found in the demo repo. We will show key snippets here: ### Evaluate the snapshot ```groovy withCredentials([string(credentialsId: 'invariant-api-token-id', variable: 'INVARIANT_API_TOKEN')]) { ``` Jenkins can store credentials as Jenkins secrets. Here we retrieve the 'invariant-api-token-id' secret and make it available to the invariant CLI, authenticating the client. ```groovy def output = sh(script: """ #!/bin/bash set -e .venv/bin/invariant run --condensed --target ${env.NETWORK_SNAPSHOT_DIR} """, returnStdout: true).trim(); ``` This runs the “invariant run” command, which sends the network snapshot at the directory specified by --target to Invariant. Invariant will handle the heavy lifting of securely creating and destroying the digital twin network, understanding and processing the connectivity and access policy requirements, and compiling derived model information in a useful and diff-able format. `--condensed` This requests ‘condensed output’ which summarizes the outcome in a single line (pass / fail / error). ```groovy def linesArray = output.split('\n'); def firstLine = linesArray.length > 1 ? linesArray[0].trim() : ""; def lastLine = linesArray.length > 0 ? linesArray[-1].trim() : ""; // Validate outcome if (lastLine == "outcome: All rules passed") { echo "SUCCESS: Invariant check passed."; } else { echo "WARNING: Invariant check failed. Last line was: '${lastLine}'. Full output:\n${output}"; testFailed = true; } ``` If all tests passed within Invariant, the last line of the output will always read “outcome: All rules passed”. We can use this to decide whether to pass or fail the task, so that failing Invariant tests fail the task. ### Fetch and archive reports ```groovy env.INVARIANT_REPORTS.split(' ').each { type -> sh(script: """ #!/bin/bash set -e # withCredentials injects INVARIANT_API_TOKEN into env .venv/bin/invariant show ${type} --snapshot ${invariant_snapshot} --json > "${currentOutputDir}/${type}.json" """); }; ``` Here we use the “invariant show” command, which downloads the analysis report named by `${type}`. We request the output type using ‘--json’ and write the file for later use. ```groovy archiveArtifacts artifacts: "${currentOutputDir}/*.json", fingerprint: true; ``` This attaches all fetched reports to the Jenkins build for later examination. ### Compare against current network ```groovy copyArtifacts( projectName: targetProjectName, selector: targetSelector, filter: "${currentOutputDir}/*.json", target: previousOutputDir, fingerprintArtifacts: true, flatten: true, ) ``` We can fetch the previously fetched network data from a prior Jenkins build for comparison. In our example we have a branch called “golden_branch”, comparisons are performed against the most recent build for that branch. ```groovy sh """ diff -urN "${previousOutputDir}/" "${currentOutputDir}/" > "${diffOutputDir}/0_invariant_data.diff" || true """ ``` This performs a diff between the network data in the comparison target (golden branch) and the current build. ## Resources * Jenkinsfile and Jenkins Agent Dockerfile
https://github.com/InvariantTech/demo/tree/main/automation_jenkins/ * The example network snapshot (working).
https://github.com/InvariantTech/demo/tree/main/enterprise_quick/ --- --- title: Network Snapshots Overview sidebar_label: Overview --- import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; A Network Snapshot in Invariant is a digital twin of your network, enabling offline analysis and validation. It's constructed by Invariant using your device configuration files and other supplemental data, with [Batfish](https://www.batfish.org/) as the core network modeling engine. This approach allows Invariant to analyze your network's behavior—routing, security policies, and connectivity—without requiring live access to your devices, ensuring a secure and isolated environment for pre-change validation and ongoing monitoring. ## How Snapshots Work Invariant takes your provided configuration files, processes them (including pre-processing steps like credential stripping for security), and feeds them into Batfish. Batfish then builds a comprehensive, vendor-neutral model of your network. This model understands device configurations, routing protocols, firewall rules, and more, effectively creating a simulated version of your live network. **Credential Stripping:** Invariant and Batfish analyze configurations offline. Sensitive information like passwords, SNMP community strings, or other credentials are not required in the configurations for analysis and should be removed or replaced with placeholders before creating a snapshot for optimal security. ## Supported Vendors Invariant supports all network device vendors that Batfish supports. This includes a wide range of physical and virtual devices. You typically provide the output of `show running-config` (or its equivalent) for each device. Key supported vendors include: * Arista * Cisco (IOS, IOS-XE, IOS-XR, NX-OS, ASA) * Juniper (JunOS - EX, MX, SRX, PTX, T-Series) * Palo Alto Networks * Fortinet * F5 BIG-IP * AWS (VPC configurations) * SONiC * Cumulus Linux * Check Point For a complete list and specific instructions for each vendor, refer to the [Batfish documentation on supported vendors](https://batfish.readthedocs.io/en/latest/formats.html) and Invariant's [Supported Platforms](/Reference/SupportedPlatforms) page. ## Core Concepts ### Network as Code in Native Configuration Invariant embraces the "Network as Code" paradigm by working directly with the native configuration syntax of your network devices. You don't need to translate your configs into an intermediate format. ``` ! Example: A snippet from a Cisco IOS configuration file hostname MyRouter ! interface GigabitEthernet0/0 ip address 192.168.1.1 255.255.255.0 no shutdown ! router ospf 1 network 192.168.1.0 0.0.0.255 area 0 ``` This allows you to use your existing configuration management workflows and version control systems. ### Simulated Protocol Negotiation The digital twin built by Invariant and Batfish simulates how your network devices would negotiate and establish various network protocols. This includes: * **BGP:** Session establishment, route advertisement, and policy application. * **OSPF:** Adjacency formation and Link-State Advertisement (LSA) exchange. * **IPSec:** Tunnel establishment and security associations. * **FIB Calculation:** Determination of Forwarding Information Bases (RIBs to FIBs) on each device. This simulation provides a deep understanding of the network's control plane and data plane behavior. ### Inserting Missing Pieces Real-world networks interact with external entities (like the Internet or private backbones) and have operational states that aren't always fully captured in static configurations. Invariant allows you to provide supplemental data to model these aspects accurately: * **ISP Connections:** Model your Internet Service Provider connections using an `isp_config.json` file in the `batfish/` directory. This helps simulate default routes and external connectivity. ```json title="batfish/isp_config.json (Conceptual Example)" { "borderInterfaces": [ { "borderInterface": { "hostname": "border-router1", "interface": "GigabitEthernet0/0" } } ], "ispNodeInfo": [ { "asn": 65000, "name": "MyISP", "role": "TRANSIT" } ] } ``` * **eBGP Messages:** Specify external BGP announcements using `external_bgp_announcements.json` (Batfish format) to model routes learned from external peers. * **Layer 1/2 Details:** If L3 inference isn't sufficient (e.g., due to IP address reuse or link-local addressing), provide a `layer1_topology.json` file (Batfish format) with explicit cabling information. * **Operational States:** Use `runtime_data.json` (Batfish format) to specify operational states like interface up/down status or current bandwidth, which can override what's inferred from static configs. ### Model Quality and Fine-Tuning The accuracy of Invariant's analysis depends on the quality of the network model. It's crucial to verify this model, especially during initial onboarding. * **Invariant Reports:** Use reports like `file_parse_status`, `ignored_lines`, `undefined_references`, and `unconnected_nodes` to identify potential issues in how configurations were parsed or interpreted. * **Explicit Vendor Specification:** If Batfish struggles to auto-detect a device's vendor, you can add a RANCID-style header to the configuration file (e.g., `!RANCID-CONTENT-TYPE: cisco-ios`). Careful review and fine-tuning ensure the digital twin accurately reflects your network's intended state and behavior. ## Directory Structure To create a network snapshot for Invariant, organize your files into a specific directory structure. Invariant processes this directory to build the network model. ```bash my_network_snapshot/ ├── aws_configs/ # (Optional) AWS resource configurations (JSON) ├── batfish/ # (Optional) Batfish-specific supplemental data │ └── isp_config.json # Example: ISP modeling ├── configs/ # Core device configuration files (e.g., Cisco, Juniper) ├── def/ # (Optional) Network and service definitions (Aerleon/Capirca YAML or .def/.svc) │ ├── networks.yaml │ └── services.yaml ├── hosts/ # (Optional) Host configurations and iptables ├── invariant/ │ ├── locations/ # (Optional) Named location definitions (YAML) │ │ └── locations.yaml │ └── policies/ # (Required for validation) Invariant rule files (YAML) │ └── my_policy.yaml └── probe_targets.yaml # (Optional) Custom probe targets for connectivity tests ``` Refer to the [Snapshot Reference](/Reference/Snapshots) for detailed information on each directory and file format. ## Lifecycle The lifecycle of a network snapshot in Invariant involves several key stages: 1. **Upload:** The user packages their network configurations and supplemental data into the defined directory structure. This snapshot is then uploaded to Invariant, typically using the CLI. ```bash invariant run --target my_network_snapshot/ --network production_dc ``` 2. **Evaluation (Eval):** Once uploaded, Invariant processes the snapshot: * It uses Batfish to parse the configurations and build a detailed, vendor-neutral model of the network (the digital twin). * It then evaluates this model against any Invariant rules (access policies, critical flows) defined in the `invariant/policies/` directory. 3. **Data Access:** After evaluation, Invariant makes a rich set of data and reports available. This data provides insights into the network model (e.g., routing tables, BGP sessions) and the results of the rule validations. ```bash # View routing table for a specific node invariant show routes --snapshot --json | jq '.[] | select(.Node == "my_router")' # Check for policy violations invariant show policy_violations --snapshot ``` 4. **Iterative Analysis (Try Rule):** The generated model and reports allow for iterative analysis. Users can: * Query various aspects of the network model. * Refine existing Invariant rules or add new ones and re-evaluate them against the *same uploaded snapshot* without needing to re-upload all configuration files (if only rules change). This is typically done by modifying rule files and re-running `invariant run`. * Use Invariant's "Try Rule" feature in the UI (or by crafting specific queries) to test hypotheses about network behavior. This lifecycle enables both pre-change validation (by uploading a proposed set of configurations) and ongoing monitoring of the production network. --- --- title: Map Screen --- Invariant generates a visual network map for all uploaded network snapshots. The generated network map includes all on-prem devices, cloud network devices, and hosts. It includes any artificial additions to the network snapshot such as ISPs (see section Model Fine-Tuning). To access the maps screen for a snapshot: 1. Navigate to the Networks section. 2. Select the Network which contains the snapshot you want. 3. Click on the network health graph to access the snapshot list for the network. 4. Select the target snapshot from the snapshot list. The snapshot network map is now visible in the UI. ## Network Health Information The Invariant UI provides a visual **Network Health** graph for each Network on the main dashboard / map screen. - The graph x-coordinate follows the date. - The graph y-coordinate counts the number of rules evaluated when the snapshot was uploaded. - The marker color can appear black (errors prevented evaluation), yellow (some rules were skipped or errors present), red (one or more rules failed), or green (all rules OK). ## Validation Results On the left side of the network map screen in the floating panel is a section which summarizes the validation result. It might say something like: > Rule Checks > 1 / 1 access policy rule failed. > 0 critical flow rules OK. This summary is clickable. Clicking it opens the Traces view. ## Traces View The traces view contains a list of rules which passed or failed. Each rule is summarized with a table which looks like: ``` #0 - FAILED Policy validate-mcs-acl Comment Validate mcs acl on cores Type egress-deny-others Packet UDP 172.20.131.4:49152 -> 172.18.5.192:33434 Start @enter((us-sfo101-cs1)[irb.150]), @enter((us-sfo101-cs2)[irb.150]) ``` Each rule has two buttons, "View Data" and "Visualize". The "Visualize" button highlights the path or paths taken by traceroutes in the rule result. The "View Data" button displays the full result data, similar to what would appear in the `critical_flows_details` or `access_policy_details` pages. --- --- title: Model Data Files --- Invariant loads your network snapshot into a network simulation environment which simulates protocols like IPSec, BGP, OSPF, and others, and generates simulated route tables for all devices and VRFs. Invariant makes all aspects of this simulated network available to you through **data files**. You can use these data files to: * Examine the simulated network in detail * Compare data files between two versions of your network * Understand the simulated environment in which Invariant rules were evaluated * Archive the simulated network data files for query over time ## Model Data Files Listing Model data files are organized into these categories. * **Network Information:** Details about nodes, interfaces, IP addressing, VLANs, and routing tables (RIBs). * **Topology:** Layer 3 adjacencies and other connectivity information. * **Routing Protocols:** Status and configuration of BGP, OSPF, and IPSec sessions. * **Model Creation Details:** Information on how device configurations were parsed and interpreted, including any warnings or ignored lines. A full listing appears here. ### Network Information Files Complete information about the network model. | File | Description | Rows Correspond To | |------|------|------| | [nodes](/Reference/Output/NetworkInformation/nodes) | Network nodes (devices, hosts, cloud resources). | Number of nodes loaded in the model. | | [interfaces](/Reference/Output/NetworkInformation/interfaces) | Network interfaces. | Number of interfaces loaded in the model. | | [named_structures](/Reference/Output/NetworkInformation/named_structures) | Vendor-independent structures (ACLs, VXLANs, etc). | Number of abstract structures loaded in the model. | | [vlan_properties](/Reference/Output/NetworkInformation/vlan_properties) | VLANs and VXLANs.| Number of VLANs and VXLANs loaded in the model. | | [hsrp_properties](/Reference/Output/NetworkInformation/hsrp_properties) | HSRP groups. | Number of HSRP groups loaded in the model. | | [mlag_properties](/Reference/Output/NetworkInformation/mlag_properties) | MLAG domains. | Number of MLAG domains loaded in the model. | | [ip_owners](/Reference/Output/NetworkInformation/ip_owners) | IP assignments. | Number of interfaces with IP addresses assigned. | | [vrrp_properties](/Reference/Output/NetworkInformation/vrrp_properties) | VRRP groups. | Number of VRRP groups loaded in the model. | | [routes](/Reference/Output/NetworkInformation/routes) | Routing tables. | Number of routing table entries across all devices in the model. | ### Topology Files | File | Description | Rows Correspond To | |------|------|------| | [layer_3_edges](/Reference/Output/Topology/layer_3_edges) | Layer 3 edges. | Number of layer 3 edges in the model. | | [layer_1_edges](/Reference/Output/Topology/layer_1_edges) | User-provided layer 1 edges. | Number of user-provided layer 1 edges in the model. | | [edges](/Reference/Output/Topology/edges) | Layer 3 edges (duplicate). | Number of layer 3 edges in the model. | ### BGP Files | File | Description | Rows Correspond To | |------|------|------| | [bgp_process_config](/Reference/Output/BGP/bgp_process_config) | Configuration settings for BGP processes. | Number of BGP processes loaded in the model. | | [bgp_peer_config](/Reference/Output/BGP/bgp_peer_config) | Configuration settings for configured BGP peerings. | Number of configured BGP peerings loaded in the model. | | [bgp_session_compatibility](/Reference/Output/BGP/bgp_session_compatibility) | Issues found in configured BGP peerings. | Number of configured BGP peerings with issues found. | | [bgp_session_status](/Reference/Output/BGP/bgp_session_status) | Status information for configured BGP peerings. | Number of configured BGP peerings loaded in the model. | | [bgp_edges](/Reference/Output/BGP/bgp_edges) | BGP edges. | Number of BGP edges loaded in the model. | | [bgp_ribs](/Reference/Output/BGP/bgp_ribs) | BGP RIBs. | Number of BGP RIB entries across all devices in the model. | ### OSPF Files | File | Description | Rows Correspond To | |------|------|------| | [ospf_process_config](/Reference/Output/OSPF/ospf_process_config) | OSPF routing processes. | Number of running OSPF processes in the model. | | [ospf_interface_config](/Reference/Output/OSPF/ospf_interface_config) | Interface-level OSPF configuration details. | Number of interfaces running OSPF. | | [ospf_area_config](/Reference/Output/OSPF/ospf_area_config) | OSPF areas. | Number of OSPF areas in the model. | | [ospf_session_compatibility](/Reference/Output/OSPF/ospf_session_compatibility) | OSPF sessions. | Number of OSPF sessions in the model. | ### Inconsistent Traffic Files | File | Description | Rows Correspond To | |------|------|------| | [subnet_multipath](/Reference/Output/InconsistentTraffic/subnet_multipath) | Examples of traffic flows that are treated differently (i.e., dropped versus forwarded) by different paths in the network. | Number of example flows found. | | [loopback_multipath](/Reference/Output/InconsistentTraffic/loopback_multipath) | Examples of traffic flows between loopbacks that are treated differently (i.e., dropped versus forwarded) in the presence of multipath routing. | Number of example flows found. | ### Model Creation Files Files in this section illustrate how the digital twin model was created from the provided input. | File | Description | Rows Correspond To | |------|------|------| | [defined_structures](/Reference/Output/ModelCreation/defined_structures) | Structure definitions as they appear in config files (ACLs, VXLANs, etc). | Number of structure definitions found. | | [referenced_structures](/Reference/Output/ModelCreation/referenced_structures) | Structure references as they appear in config files (ACLs, VXLANs, etc). | Number of references to defined structures. | | [unused_structures](/Reference/Output/ModelCreation/unused_structures) | Structure definitions not referenced or used. | Number of unused structure definitions. | | [undefined_references](/Reference/Output/ModelCreation/undefined_references) | Structure references with no matching definition. | Number of undefined references. | | [unconnected_nodes](/Reference/Output/ModelCreation/unconnected_nodes) | Nodes with no connection to any other node in the model. | Number of unconnected nodes. | | [file_parse_status](/Reference/Output/ModelCreation/file_parse_status) | Parsing status of snapshot files. | Number of files found in the snapshot. | | [ignored_lines](/Reference/Output/ModelCreation/ignored_lines) | Lines parsed but ignored by the model. | Number of ignored lines. | | [parse_warnings](/Reference/Output/ModelCreation/parse_warnings) | Warnings that occurred when parsing snapshot files. | Number of warnings produced. | Full documentation including columns can be found in the [Output Reference](/Reference/Output/Output). ## Access from CLI You can access data files using the `invariant show ` command. ```bash # Fetch 'routes' data file from snapshot by ID $ invariant show routes --snapshot adf11172-9f8a-4333-b7c7-f9f0ecefe8d9 # By default, uses the last uploaded snapshot for this terminal session $ invariant show routes ``` ### JSON Output For programmatic use or detailed inspection, you can output data files in JSON format using the `--json` flag. ```bash # Get interface properties as JSON invariant show interfaces --json # Get BGP session status as JSON invariant show bgp_session_status --json > bgp_sessions.json # Get BGP session status as JSON (no whitespace) invariant show bgp_session_status --fast-json > bgp_sessions.json ``` ### TSV Output Tab-Separated Values (TSV) format is also available using the `--tsv` flag, useful for spreadsheet programs or simple scripting. ```bash # Get OSPF session compatibility as TSV invariant show ospf_session_compatibility --tsv # Get IP ownership details as TSV invariant show ip_owners --tsv > ip_owners.tsv ``` ### Accessing Prior Snapshots To access data files from a specific previous snapshot, use the `--snapshot ` flag. You can list snapshot UUIDs using the `invariant snapshots` command. ```bash # Show routes from a specific previous snapshot invariant show routes --snapshot f17e9368-67fd-4094-b191-4da3f837eb60 --json ``` --- For information on how Invariant uses this model data to validate your network, see: * [Security Validation](/Security-Validation/Overview) * [Connectivity Validation](/Connectivity-Validation/Overview) --- --- title: History --- Invariant keeps a history of analysis results for uploaded snapshots. The snapshot history is most useful when snapshots are organized into well-named networks - see [Best Practices](#best-practices). * **Track Network History:** Observe how your network configuration and behavior have changed over time. * **Network Health:** Show when the network went out of compliance with security or connectivity requirements. * **Audit and Compliance:** Maintain a verifiable history of network configurations for compliance reporting and security audits. * **Troubleshoot Incidents:** Quickly compare a problematic current or proposed state against known-good historical snapshots to identify impactful changes. * **Pinpoint Issues:** Determine exactly when a misconfiguration or policy violation was introduced by examining historical data. The following sections detail best practices for organizing your snapshot history, leveraging it for network health monitoring, and accessing historical data via the Invariant CLI. ## Best practices ### Always upload using `--network`. Don't mix sites on one network. Avoid the default network. Always create a Network resource in Invariant specific to the snapshot part of the network the snapshot captures. For example, when taking a snapshot of a specific network (e.g. "IAD-prod"), create one network (or more, see below) for snapshots of just that site. This is important because Invariant can produce a network health chart per-network. You will also configure alerting rules and set security and connectivity requirements per-network. Invariant can also serve as a searchable archive of prior network snapshots. All of these functions work best when a network contains snapshots of a single site. ### Don't mix live network snapshots with change proposal snapshots in the same network. Similar to above, always create distinct networks for snapshots created by capturing the live state of the network vs snapshots that are manually edited and represent a planned or proposed modification to the network. A self-documenting naming stratgy can be helpful here. We suggest the following naming scheme. * **`-synced`**: For Networks that are regularly synced with your live network environment, append `-synced` to the network name. * Example: `IAD-prod-synced` * Network monitoring, audit, and drift detection would build on your `-synced` network. * **`-golden`**: For Networks that track the 'golden' or intended configuration of the network, append `-golden` to the network name. * Example: `IAD-prod-golden` * Compare this network to the `-synced` network, if you have it, to see the total impact of your proposed change, including calculated route tables. * **`-proposed-`**: For Networks that contain proposed changes. * Example: `IAD-prod-proposed-06-25-maintenance` * Example: `IAD-prod-proposed-JIRA-803` * Use these networks to explore a possible change to the network. You may wish to delete these networks after use. Other network roles might include root cause analysis (`-rca`) or exploratory (`-exp`). # Network Health Invariant tracks the health of your network over time by storing key metrics from each snapshot analysis, allowing you to observe trends and identify when issues may have arisen. ## Dashboard The Invariant UI provides a visual **Network Health** graph for each Network on the main dashboard / map screen. - The graph x-coordinate follows the date. - The graph y-coordinate counts the number of rules evaluated when the snapshot was uploaded. - The marker color can appear black (errors prevented evaluation), yellow (some rules were skipped or errors present), red (one or more rules failed), or green (all rules OK). ## Health Data Retrieve raw historical health data using the `invariant snapshots` CLI command. ```bash # List snapshots for "IAD-prod-synced" in TSV format invariant snapshots --network IAD-prod-synced --tsv uuid created_at network_name cf_violations ap_violations status errors_count adf11172-9f8a-4333-b7c7-f9f0ecefe8d9 2025-02-27T01:47:50.811850+00:00 IAD-prod-synced 0 0 COMPLETE 0 6c334806-126c-4b63-bafe-495b39fdf995 2025-02-27T01:47:50.811850+00:00 IAD-prod-synced 0 1 COMPLETE 0 ``` # List Network Snapshots from the CLI Use the `invariant snapshots` command to list prior snapshot analysis results for your networks. ```bash # List snapshots for network IAD-prod-synced $ invariant snapshots --network IAD-prod-synced +--------------------------------------+-----------------+----------------------------------+----------+----------------+----------------+--------------+ | uuid | network | created_at | status | cf_violations | ap_violations | errors_count | +--------------------------------------+-----------------+----------------------------------+----------+----------------+----------------+--------------+ | adf11172-9f8a-4333-b7c7-f9f0ecefe8d9 | IAD-prod-synced | 2025-02-27T01:47:50.811850+00:00 | COMPLETE | 0 | 0 | 0 | | 6c334806-126c-4b63-bafe-495b39fdf995 | IAD-prod-synced | 2025-02-27T01:47:50.811850+00:00 | COMPLETE | 0 | 1 | 0 | +--------------------------------------+-----------------+----------------------------------+----------+----------------+----------------+--------------+ # List snapshots for the default network $ invariant snapshots ``` Control the output format with `--tsv` or `--json`. ```bash # List snapshots in TSV format $ invariant snapshots --network IAD-prod-live --tsv uuid created_at network_name cf_violations ap_violations status errors_count adf11172-9f8a-4333-b7c7-f9f0ecefe8d9 2025-02-27T01:47:50.811850+00:00 IAD-prod-synced 0 0 COMPLETE 0 6c334806-126c-4b63-bafe-495b39fdf995 2025-02-27T01:47:50.811850+00:00 IAD-prod-synced 0 1 COMPLETE 0 # List snapshots in JSON format $ invariant snapshots --network IAD-prod-synced --json ``` Use the snapshot ID (uuid) from the listing with `invariant show` to access detailed reports for a specific snapshot. ```bash # Example: Show the 'routes' report for a specific snapshot $ invariant show routes --snapshot adf11172-9f8a-4333-b7c7-f9f0ecefe8d9 --tsv ``` See [API > CLI](/API/CLI) for complete CLI documentation and [Output Overview](/Reference/Output/Output) for details on available reports. --- --- title: Security Validation Overview sidebar_label: Overview --- Invariant empowers network and security teams to rigorously validate their network configurations against defined security policies. With Invariant you can identify potential security misconfigurations, ensure compliance, and investigate network behavior without impacting the live environment. This overview explores how Invariant facilitates security validation through its rule evaluation models, various enforcement strategies, and its utility in compliance and research. ## Evaluation Models Invariant provides flexible ways to evaluate your network against security rules: ### On Upload The primary method for security validation is through including rules in the uploaded snapshot. These are access policy and critical flow rules defined in YAML files within your snapshot's `invariant/policies/` directory. When you upload a snapshot using the `invariant run` command, Invariant automatically: 1. Builds a model of your network from the provided configuration files. 2. Evaluates all installed rules against this model. 3. Generates detailed reports, such as `policy_ok`, `policy_violations`, `critical_flows_ok`, and `critical_flows_violations`, which indicate the pass/fail status of each rule and provide example traceroutes for violations or successful critical flows. This model is ideal for continuous validation and as part of automated CI/CD pipelines. ```bash # Example: Running Invariant to evaluate installed rules invariant run --target /path/to/your/snapshot/ ``` ### Interactive/Focused Evaluation While Invariant's core strength lies in comprehensive snapshot analysis, users often need to test specific scenarios or rule ideas without waiting for a full snapshot upload or impacting the main policy set. This can be achieved by: 1. **Crafting Specific Policy Files:** Create temporary or focused policy files in a test snapshot (or a branch in your configuration-as-code repository) to evaluate particular "what-if" scenarios or new rule logic. Running `invariant run` on this targeted snapshot provides the validation. 2. **Detailed Report Analysis:** The reports generated from a full snapshot run (e.g., `policy_details`, `critical_flows_details`) contain extensive information, including virtual traceroutes. Analyzing these reports helps understand the impact of individual rules and network paths. 3. **Leveraging Underlying Capabilities:** Invariant builds upon the powerful network modeling and querying capabilities of Batfish. While direct Batfish queries are not the primary Invariant user interface, this foundation enables Invariant's deep analysis. For instance, Batfish's `searchFilters` can exhaustively check how ACLs treat large spaces of flows, a concept Invariant's rule engine uses to validate `deny` and `deny-others` rules. This approach allows for iterative rule development and targeted troubleshooting. ## Enforcement Strategies Invariant supports multiple strategies for enforcing your security policies: ### Live Monitoring & Alerting For continuous assurance, Invariant can monitor your live network: 1. **Regular Syncing:** Periodically upload snapshots of your live network configurations to Invariant. This can be automated using scripts or CI/CD tools. 2. **Automated Alerts:** Configure [Notification Groups](/Configuration/notification_groups) in Invariant. If an uploaded snapshot results in rule violations, Invariant automatically sends alerts to the specified email addresses. 3. **Incident Analysis & Remediation Tracking:** The [Snapshot History](/Network-Snapshots/Snapshot-History) provides a time-series view of your network's compliance. In case of an incident, you can analyze past snapshots to understand when a violation was introduced and track the time to remediation. This strategy helps in quickly detecting and responding to unintended changes or drifts from the desired security posture in the production environment. ### Pre-flight Validation Prevent misconfigurations from ever reaching your production network by validating changes *before* deployment: 1. **Test Proposed Changes:** When planning a network change (e.g., new ACLs, routing modifications), apply these changes to a copy of your current configurations (e.g., in a separate Git branch). 2. **Analyze in Invariant:** Upload this "candidate" snapshot to Invariant and run the rule evaluation. 3. **Prevent Deployment on Failure:** If Invariant reports violations, the change should not be deployed until the issues are resolved. This proactive approach significantly reduces the risk of outages or security breaches. 4. **CI/CD Integration:** Integrate Invariant checks into your CI/CD pipeline (e.g., using Jenkins, as demonstrated in our [Preflight Automation Demo](/Automation-Cookbooks/Jenkins)). This automates the validation process, ensuring all changes are vetted. 5. **Golden Configuration:** Maintain a "golden" snapshot or branch representing the ideal, validated state of your network. Proposed changes can be compared against this baseline to identify any deviations. Pre-flight validation is a cornerstone of a robust network-as-code practice. ## PCI-DSS Compliance Support Invariant's security validation capabilities can be a valuable asset in achieving and maintaining PCI-DSS (Payment Card Industry Data Security Standard) compliance: * **Network Segmentation Validation:** Use `deny` and `deny-others` rules to rigorously verify that the Cardholder Data Environment (CDE) is properly isolated from other network segments, allowing only explicitly authorized traffic. * **Firewall Rule Verification:** Ensure that firewall configurations (represented as ACLs or zone policies in Invariant) permit only necessary ports and protocols into and out of the CDE. * **Continuous Monitoring:** Employ live monitoring to detect any configuration drift that could compromise PCI-DSS compliance, providing timely alerts. * **Auditable Evidence:** Invariant's reports and snapshot history serve as auditable proof of network policy enforcement and compliance checks over time. By modeling and validating network access controls, Invariant helps organizations demonstrate due diligence and maintain a compliant security posture. ## Network Security Research Beyond routine validation, Invariant serves as a powerful tool for proactive network security research and investigation: ### Identifying Exposures * **Unintended Access Paths:** Write `deny` rules for traffic that should *never* be allowed (e.g., direct internet access to internal management interfaces) or `deny-others` rules for sensitive zones to discover any existing, unapproved access paths. * **Zero Trust Backlog Generation:** Use `deny-others` rules with `enforce: false` (see [Build a Zero Trust deployment backlog](/Guides/Advanced-Use-Cases/Zero-Trust/build-a-zero-trust-deployment-backlog-using-invariant)) to identify all currently permitted flows into or out of a segment. This report becomes a backlog for creating an explicit Zero Trust policy. * **High-Risk Protocol Search:** Search for any allowed instances of high-risk protocols (e.g., Telnet, unencrypted FTP) to sensitive areas. ### Vulnerability Assessment Context While Invariant doesn't perform vulnerability scanning itself, it provides crucial context. By combining Invariant's reachability data (what can talk to what, and over which ports/protocols) with information from vulnerability scanners (e.g., a list of unpatched services on specific hosts), security teams can: * Prioritize patching efforts by focusing on vulnerabilities that are actually exploitable given the current network configuration. * Identify compensating controls (like ACLs) that might mitigate the risk of an unpatched vulnerability. ### Validating ACL/Firewall Soundness Invariant's underlying analysis, inherited from Batfish, can help identify issues within ACLs themselves, such as: * **Shadowed Rules:** Lines in an ACL that will never be matched because preceding lines cover all their conditions. * **Redundant Rules:** Unnecessary rules that don't change the overall behavior of the ACL. Identifying and rectifying these issues improves ACL efficiency and maintainability, reducing the chance of errors. By providing a detailed, queryable model of the network, Invariant enables security professionals to ask complex "what-if" questions and thoroughly investigate the security posture of their infrastructure. --- --- title: "Guide: deny-others rules" --- The `deny-others` rule is one of Invariant's most powerful tools for enforcing network segmentation and Zero Trust principles. It allows you to define a broad scope of traffic that should be denied by default, with specific, explicitly permitted exceptions. This guide will walk you through understanding, writing, and troubleshooting `deny-others` rules. The core purpose of a `deny-others` rule is to implement a "default deny" posture for a defined segment of your network. You specify what traffic *should* be allowed, and Invariant verifies that all other traffic within a defined scope is indeed blocked. **Key Components:** * **Target Network (`ingress-network` or `egress-network`):** Defines the primary network segment the rule applies to. For `ingress-deny-others`, this is the destination network. For `egress-deny-others`, this is the source network. * **Scope of Denial (`within` clause - Optional):** Narrows down the type of traffic that the "deny by default" logic applies to. If omitted, it applies to all traffic targeting (for ingress) or originating from (for egress) the network. * **Explicit Permissions (`deny-all-except.flows` clause - Required):** A list of specific traffic flows that *are* permitted within the defined scope. **High-Level Evaluation Logic:** Invariant evaluates a `deny-others` rule by performing an exhaustive search: 1. **Identify Target Network:** Resolves the `ingress-network` or `egress-network` to specific IP spaces. 2. **Identify Scope of Denial:** Resolves the traffic characteristics defined in the `within` clause (e.g., specific protocols, ports, source/destination IPs). If `within` is not present, the scope is all traffic. 3. **Identify Explicitly Permitted Flows:** Resolves the flows listed in `deny-all-except.flows`. 4. **Search for Violations:** Invariant searches for any traffic flow that: * Matches the **Target Network**. * Falls within the **Scope of Denial** (matches the `within` clause). * Is *NOT* part of the **Explicitly Permitted Flows** (does not match any flow in `deny-all-except.flows`). * AND can be **successfully delivered** through the network (i.e., passes all routing and firewall configurations). 5. **Violation:** If such a flow is found, the `deny-others` rule is violated because traffic that should have been denied (as it wasn't explicitly permitted) was allowed. **Use Cases:** * Securing sensitive zones (e.g., PCI CDE, databases) by allowing only minimal necessary access. * Implementing Zero Trust network segmentation by defining what traffic is allowed and denying everything else. * Gradually migrating to a Zero Trust model by using `enforce: false` to discover existing allowed traffic (see [Build a Zero Trust deployment backlog](/Guides/Advanced-Use-Cases/Zero-Trust/build-a-zero-trust-deployment-backlog-using-invariant)). ## Writing `deny-others` Rules Let's construct an `ingress-deny-others` rule to control SSH access to a `DATACENTER` network. ### Defining the Target Network First, specify the network segment this rule protects. For an ingress rule, this is the destination. ```yaml access-policy: - name: datacenter-ssh-control ingress-network: DATACENTER # DATACENTER is a named network, e.g., 10.1.0.0/16 # ... ``` ### Defining the Scope of Denial (`within` clause) The `within` clause defines the broader category of traffic you intend to control with this rule. All traffic matching `within` will be denied unless explicitly allowed by `deny-all-except`. * **Purpose:** To narrow down what traffic is subject to the "deny by default" part of the rule. * **Common Scenarios:** * Scoping by protocol: `within: [{protocol: tcp}]` (controls all TCP traffic to `DATACENTER`). * Scoping by protocol and port: `within: [{protocol: tcp, destination-port: SSH}]` (controls all SSH traffic to `DATACENTER`). * Scoping by source and protocol: `within: [{source-address: RFC1918, protocol: tcp}]` (controls all internal TCP traffic to `DATACENTER`). * **Note:** If `within` is omitted, the scope is *all* traffic to/from the target network. This is very broad and usually desired only if `deny-all-except` is also very comprehensive. For our SSH example, we want to control all TCP traffic destined for the SSH port on our `DATACENTER` network: ```yaml # ... rules: - type: ingress-deny-others comment: Only MGMT_SERVER can SSH into DATACENTER within: - protocol: tcp destination-port: SSH # Assumes SSH is defined as tcp/22 # ... ``` ### Defining Explicit Permissions (`deny-all-except.flows` clause) This clause lists the specific flows that *are* allowed, creating exceptions to the denial defined by `ingress-network` and `within`. * **Structure:** A list of flow definitions. Each flow can specify `source-address`, `destination-address` (though usually redundant for ingress rules if `ingress-network` is specific), `destination-port`, `source-port`, and `protocol`. We want to allow SSH only from `MGMT_SERVER`: ```yaml # ... deny-all-except: flows: - comment: Allow SSH from MGMT_SERVER to DATACENTER source-address: MGMT_SERVER # e.g., 192.168.1.10/32 protocol: tcp destination-port: SSH ``` ### Complete Example Rule ```yaml access-policy: - name: datacenter-ssh-control comment: Controls SSH access into the DATACENTER network owner: security-team@example.com ingress-network: DATACENTER rules: - type: ingress-deny-others comment: Only MGMT_SERVER can SSH into DATACENTER within: - protocol: tcp destination-port: SSH deny-all-except: flows: - comment: Allow SSH from MGMT_SERVER to DATACENTER source-address: MGMT_SERVER protocol: tcp destination-port: SSH ``` This rule states: "For any TCP traffic going to the SSH port on any host in `DATACENTER`, deny it, *unless* it is TCP traffic from `MGMT_SERVER` to the SSH port." ### Best Practices * **Start Broad, Permit Specific:** It's often easier to define a broader `within` scope (e.g., all TCP traffic to a sensitive zone) and then list the few necessary permitted flows in `deny-all-except`. * **Use `enforce: false`:** When creating new `deny-others` rules or migrating to a Zero Trust model, start with `enforce: false`. This allows Invariant to report "violations" (i.e., traffic that *is* currently allowed but *would be* denied by this rule if enforced) without failing your CI/CD pipeline. Use the `policy_violations_unenforced` report to build a backlog of flows to explicitly allow or block. * **Be Precise:** Ensure your network and service definitions (`def/` directory) are accurate. A typo in an IP address or service name in `deny-all-except` can lead to unintended denials. ## Understanding Violations and `policy_details` When a `deny-others` rule is violated, it means Invariant found a traffic flow that: 1. Matched the `ingress-network` (or `egress-network`). 2. Matched the `within` clause (if specified). 3. Did *not* match any flow in `deny-all-except.flows`. 4. Was successfully deliverable through the network. Violations are reported in `policy_violations` (for enforced rules) or `policy_violations_unenforced`. The `policy_details` report provides the crucial context. **Key fields in `policy_details` for a `deny-others` violation:** * `ok: false`: Indicates a rule violation. * `flow_str`: A human-readable summary of the specific example flow that violated the rule. This is the traffic that *was* permitted but *should have been* denied according to the rule's logic. * Example: `tcp src_ip=10.5.5.5 dst_ip=10.1.0.50 dst_port=22` * `start`: The entry point of the violating flow into the network model (e.g., `@enter(edge-router[GigabitEthernet0/1])`). * `traces`: A list of one or more detailed paths (virtual traceroutes) the violating flow took through the network. ### Interpreting Traceroutes (`traces` section) The `traces` section is vital for understanding *why* a violating flow was permitted. Each trace represents a possible path: * **Structure:** A list of `hops`. Each `hop` object contains: * `node`: The hostname of the device. * `steps`: A list of actions/evaluations the packet underwent on that node. * **Key `steps` to analyze:** * `RECEIVED(interface)`: Packet arrival on an interface. * `PERMITTED(filter='filter_name', filterType='INGRESS_FILTER'|'EGRESS_FILTER')`: Packet was allowed by the specified ACL or firewall filter. * `FORWARDED(..., routes=[...], resolvedNextHopIp='...')`: Routing decision made. Shows the route(s) used and the resolved next-hop IP. * `ACCEPTED(interface)`: Packet delivered to the destination IP on the final node, via the specified local interface. By examining the `traces`, you can pinpoint which ACL allowed the unintended traffic or if routing misconfigurations led the traffic to bypass an intended security control. **Example Scenario:** If your `deny-others` rule for `DATACENTER` (denying all TCP except from `MGMT_SERVER`) is violated by a flow from `USER_SUBNET` to `DATACENTER_SERVER_A` on TCP/8080, the traceroute might show: 1. Packet from `USER_SUBNET` arrives at `dist-switch-1`. 2. `dist-switch-1` has an ACL `VLAN_INBOUND_ACL` that `PERMITTED` the flow (perhaps it has an `permit ip any any` rule). 3. `dist-switch-1` `FORWARDED` the packet towards `DATACENTER_SERVER_A`. 4. Packet `ACCEPTED` by `DATACENTER_SERVER_A`. This trace tells you that `VLAN_INBOUND_ACL` on `dist-switch-1` needs to be tightened. ## Understanding `policy_logs` The `policy_logs` report provides a summary for every rule Invariant processed, including `deny-others` rules. **Key fields for `deny-others` rules in `policy_logs`:** * `ok`: The overall pass (`true`) or fail (`false`) status of the rule. * `skipped`: `true` if the rule could not be evaluated due to syntax errors, unresolvable network/service names, or other issues. `errors` will contain details. * `errors`: A list of error messages if the rule was `skipped` or encountered problems during evaluation. * `violations`: The number of unique example flows found that violate the rule. For a passing `deny-others` rule, this will be 0. * `checks`: The number of distinct search queries or checks Invariant performed to validate this rule. For a `deny-others` rule, this typically involves Invariant constructing a query to find any flow that (matches target network AND matches `within` AND does NOT match `deny-all-except.flows`) and IS deliverable. * `check_log`: (Accessible via JSON output) Provides a detailed list of the underlying checks. For `deny-others`, this would show the parameters of the reachability search Invariant performed. **How `policy_logs` helps:** * **Confirmation:** Verifies that your rule was understood and processed by Invariant. * **Scope of Test:** The `checks` count gives an idea of the comprehensiveness of Invariant's validation for that rule. * **Debugging Skipped Rules:** If a rule is `skipped`, the `errors` field is the first place to look for why. ## Common Pitfalls and Troubleshooting * **Overly Broad `within`:** If `within` is too general (e.g., just `protocol: tcp`) and `deny-all-except` is not exhaustive, you might inadvertently block legitimate traffic that wasn't considered. * **Overly Narrow `within`:** If `within` is too specific, the "deny by default" part of the rule might not cover traffic you intended to block. For example, `within: [{protocol: tcp, destination-port: HTTP}]` will only control HTTP; other TCP traffic to the target network won't be affected by this specific `deny-others` rule. * **Typos in `deny-all-except`:** A misspelled service name or incorrect IP in `deny-all-except.flows` means that flow won't be correctly exempted, potentially leading to it being flagged as a violation (if it's deliverable) or actually blocked if the rule is enforced. * **Router Interface IPs:** If your `ingress-network` defines a subnet (e.g., `10.1.1.0/24`), and a router interface (e.g., SVI for that VLAN) has an IP within that subnet (e.g., `10.1.1.1`), traffic *to* that router interface IP might be evaluated. If your ACLs are on the router interface itself, you might want to use `destination-exclude` in `ingress-network` to exclude the router's own IPs from the target definition if the intent is to protect hosts *behind* the router. * **Interaction of `source-address` in `within`:** * Policy: `ingress-network: DATACENTER_A` * Rule: `within: [{source-address: CORP_SUBNET_B}]` * This means the rule's scope of denial applies to traffic from `CORP_SUBNET_B` destined to `DATACENTER_A`. Only flows *from* `CORP_SUBNET_B` *to* `DATACENTER_A` will be denied unless listed in `deny-all-except`. By understanding these components and how Invariant reports on them, you can effectively use `deny-others` rules to build and maintain a robust, verifiable network security posture. --- --- title: "Guide: deny rules" sidebar_label: "Guide: deny rules" --- import Tabs from '@theme/Tabs'; import TabItem from '@theme/TabItem'; Invariant `deny` rules are a powerful tool for enforcing your network security policy. They allow you to assert that specific types of traffic should *never* be successfully delivered between defined source and destination networks or locations. **Purpose of deny rules:** * Explicitly block unwanted or high-risk traffic flows. * Enforce network segmentation and isolation between different security zones. * Verify that decommissioned services are no longer accessible. * Complement `critical-flow` rules (which assert reachability) and `deny-others` rules (which define an allow-list) by explicitly defining what must be forbidden. **How Invariant evaluates deny rules:** When Invariant evaluates a `deny` rule, it exhaustively searches your network model for any possible path that would allow the specified traffic to be successfully delivered. If even one such path exists, Invariant flags a violation. This comprehensive check ensures that there are no unintended backdoors or misconfigurations that could compromise your security posture. **When to use deny rules:** * **Broad Security Postures:** To block all access from an untrusted zone (e.g., Guest Wi-Fi) to a sensitive internal zone (e.g., PCI Data). * **Specific Micro-segmentation:** To prevent a particular server from communicating with another specific server on a certain port. * **Blocking Known Bad Traffic:** To deny traffic to or from known malicious IP addresses or services. * **Validating Decommissions:** After removing a service, use a deny rule to confirm it's truly inaccessible. ## Execution Model Understanding how Invariant processes deny rules involves several key steps: 1. **Snapshot Processing:** You begin by providing Invariant with a snapshot of your network. This includes: * Device configurations (e.g., routers, switches, firewalls). * Network and service definitions (typically in YAML files within the `def/` directory). * Your Invariant policy files, including deny rules (in `invariant/policies/`). Invariant uses this information, leveraging the underlying Batfish analysis engine, to build a comprehensive digital twin of your network. 2. **Definition Resolution:** Invariant resolves all named entities used in your rules: * **Network Names:** (e.g., `INTERNAL_DB_SUBNET`, `UNTRUSTED_NETWORK`) are translated into specific IP addresses or CIDR blocks based on your `def/networks.yaml` files. * **Service Names:** (e.g., `SSH`, `HTTPS`) are resolved to their corresponding protocols and port numbers from `def/services.yaml`. * **Location Names:** (e.g., `EXTERNAL_BOUNDARY_INTERFACES`) are mapped to specific device interfaces defined in `invariant/locations/`. The resolution follows a precedence: definitions local to a rule (if applicable) > snapshot-local definitions (`def/`) > definitions installed with Invariant > built-in definitions (like `RFC1918`, `ANY`). 3. **Start Location Inference (for Egress Deny Rules):** For `egress-deny` rules, Invariant needs to determine where the traffic originates: * If `source-interface` or `enter-interface` is specified in the rule, Invariant uses those exact interfaces. * Otherwise, Invariant infers start locations based on the `source-address`. It identifies all interfaces whose configured IP addresses fall within the `source-address` range or whose primary network overlaps with it. The rule is then evaluated for traffic originating from these inferred interfaces. For `ingress-deny` rules, the `ingress-network` policy field (specifically its `destination-address`) defines the target network being protected. Invariant then considers traffic from the specified `source-address` (or `ANY` if unspecified) attempting to reach this `ingress-network`. 4. **Flow Search:** This is the core of the evaluation. Invariant performs an exhaustive search across the digital twin. For a `deny` rule, it looks for any instance where a packet matching the rule's criteria (source/destination IP, port, protocol) *successfully* reaches its destination. 5. **Evidence Compilation & Output:** * **Violation Found:** If Invariant finds *any* successful path for the traffic defined in the `deny` rule, it's a violation. * The `policy_violations` report will list the failing rule. * The `policy_details` report will provide crucial evidence: * The specific violating flow (e.g., exact source/destination IPs and ports). * A detailed virtual traceroute showing the successful path the packet took, including all hops, ACL decisions, and routing choices. * **No Violation (Rule Passes):** If the exhaustive search finds no way for the specified traffic to be delivered, the `deny` rule passes. * The rule will be listed in the `policy_ok` report. ## Writing Deny Rules Deny rules are defined in YAML files within your `invariant/policies/` directory, as part of an `access-policy`. **Basic Structure:** ```yaml title="invariant/policies/security_policy.yaml" access-policy: - name: block-untrusted-to-internal-db comment: "Prevent untrusted networks from accessing internal databases" owner: security-team@example.com # For an ingress-deny rule, ingress-network is the target being protected ingress-network: INTERNAL_DB_SUBNET rules: - type: ingress-deny comment: "Block any access from UNTRUSTED_NETWORK to internal DBs" source-address: UNTRUSTED_NETWORK # destination-address is implicitly INTERNAL_DB_SUBNET from the policy's ingress-network # protocol and destination-port can be added for more specificity, e.g.: # protocol: tcp # destination-port: MYSQL_PORT ``` **Ingress vs. Egress Deny Rules:** * **`ingress-deny`**: Use this to protect a destination network (defined in the policy's `ingress-network`) from unwanted incoming traffic. * **Example:** Deny any external traffic (e.g., from `EXTERNAL_LOCATION`) from reaching internal management interfaces (`MGMT_SUBNET`). ```yaml access-policy: - name: protect-management-interfaces ingress-network: MGMT_SUBNET rules: - type: ingress-deny comment: "Block external access to management interfaces" enter-interface: EXTERNAL_BOUNDARY_INTERFACES # Explicitly define entry point # source-address defaults to ANY if not specified from external location # destination-address is implicitly MGMT_SUBNET ``` * **`egress-deny`**: Use this to prevent a source network (defined in the policy's `egress-network`) from sending traffic to undesirable destinations. * **Example:** Deny internal servers (`INTERNAL_SERVERS_VLAN`) from initiating any connections to known malicious IP ranges (`KNOWN_MALICIOUS_IPS`). ```yaml access-policy: - name: block-outbound-to-malicious egress-network: INTERNAL_SERVERS_VLAN rules: - type: egress-deny comment: "Prevent servers from contacting known malicious IPs" # source-address is implicitly INTERNAL_SERVERS_VLAN destination-address: KNOWN_MALICIOUS_IPS ``` **Specificity: Broad vs. Narrow Rules:** The granularity of your deny rules depends on your security objectives. * **Broad Rules:** Define general security boundaries and are excellent for establishing a baseline security posture. * **Example:** Deny all traffic from the `GUEST_VLAN` to the `CORP_NETWORK`. ```yaml # In a policy with ingress-network: CORP_NETWORK - type: ingress-deny comment: "Isolate Guest VLAN from Corporate Network" source-address: GUEST_VLAN ``` Or, equivalently, in a policy with `egress-network: GUEST_VLAN`: ```yaml # In a policy with egress-network: GUEST_VLAN - type: egress-deny comment: "Isolate Guest VLAN from Corporate Network" destination-address: CORP_NETWORK ``` * **Narrow Rules:** Target very specific protocols, ports, or subnets. Useful for highly targeted restrictions or blocking specific known vulnerabilities. * **Example:** Deny Telnet access from any RFC1918 address to a group of `SENSITIVE_SERVERS`. ```yaml # In a policy with ingress-network: SENSITIVE_SERVERS - type: ingress-deny comment: "Block Telnet to sensitive servers from internal networks" source-address: RFC1918 # Built-in name for private IP space destination-port: TELNET # Built-in service name for TCP/23 protocol: tcp ``` Choosing the right level of specificity is key. Start broad to establish major zone boundaries, then add narrower rules for specific risks or compliance requirements. ## Understanding Violation Traceroutes When a `deny` rule is violated, Invariant provides a virtual traceroute in the `policy_details` report. This traceroute is crucial because it shows *exactly how* the supposedly denied traffic managed to successfully reach its destination. **Accessing Traceroutes:** Use the Invariant CLI to view the details: ```bash invariant show policy_details --json --snapshot ``` You'll then need to parse the JSON output, filtering for the specific rule that failed (e.g., by its `policy.name` and `rule.comment`). **Key JSON Fields in a Violation Traceroute:** * **`flow`**: This object describes the specific packet that constituted the violation. It includes: * `srcIp`, `dstIp`: Source and Destination IP addresses. * `srcPort`, `dstPort`: Source and Destination ports (for TCP/UDP). * `ipProtocol`: The IP protocol (e.g., `TCP`, `UDP`, `ICMP`). * **Example:** ```json "flow": { "dscp": 0, "dstIp": "10.1.1.5", // IP in INTERNAL_DB_SUBNET "dstPort": 3306, // MYSQL_PORT "ipProtocol": "TCP", "srcIp": "192.168.100.20", // IP in UNTRUSTED_NETWORK "srcPort": 54321, "tcpFlagsSyn": 1, // Indicates a TCP SYN packet (connection initiation) // ... other fields like icmpCode, icmpVar, packetLength etc. } ``` * **`start`**: Indicates where this violating flow originated within the network model. This could be an interface on a device (e.g., `@enter(edge-router-01[GigabitEthernet0/0])`) or a modeled host. * **`traces`**: An array containing one or more paths the violating flow took. Often, there's just one trace, but multiple traces can appear if Equal-Cost Multi-Path (ECMP) routing is involved. * **`disposition`**: For a `deny` rule violation, the disposition of the trace will be `ACCEPTED` (or another success-indicating status like `DELIVERED_TO_SUBNET` or `EXITS_NETWORK`), signifying the traffic reached its destination. * **`hops`**: An array detailing each network device (hop) the packet traversed. * `node`: The hostname of the device. * `steps`: An array of processing steps the packet underwent on this `node`. Each step has an `action` and `detail`: * `action: "RECEIVED"`: Packet arrived at an interface. `detail.inputInterface` shows which one. * `action: "PERMITTED"`: Packet was allowed by a filter (ACL/firewall rule). `detail.filter` gives the filter name. * `action: "FORWARDED"`: Packet was routed. `detail.outputInterface` shows the egress interface, `detail.resolvedNexthopIp` the next-hop IP, and `detail.routes` the routing table entry used. * `action: "TRANSFORMED"`: Packet was modified (e.g., by NAT). `detail.transformationType` and `detail.flowDiffs` describe the change. * `action: "ACCEPTED"` (on the final hop): Packet delivered to an IP on the device itself or an attached host. **Interpreting the Path:** The traceroute allows you to pinpoint the misconfiguration: * **Permissive ACLs:** Look for `PERMITTED` steps through ACLs or firewall policies that should have blocked the traffic. The `detail.filter` field will name the culprit ACL. * **Unexpected Routing:** If the traffic takes an unusual path, bypassing intended security controls, examine the `FORWARDED` steps and the `detail.routes` to understand why that path was chosen. * **NAT Issues:** If NAT is involved (`TRANSFORMED` steps), ensure it's behaving as expected and not inadvertently allowing access. ## Troubleshooting Deny Rule Violations When a deny rule fails, follow these steps: 1. **Verify Definitions:** * Are `source-address`, `destination-address`, `destination-port`, etc., in your rule resolving to the IP addresses, subnets, and services you intend? * Use `def/networks.yaml` and `def/services.yaml` to confirm. * The `resolved_as` field in the `policy_details` output for the failing rule shows how Invariant interpreted your named definitions. 2. **Analyze the Traceroute(s):** * Carefully examine each hop and step in the `traces` provided in `policy_details`. * Identify any ACLs that `PERMITTED` the flow unexpectedly. * Note the routing decisions (`FORWARDED` steps) that led the packet along the violating path. 3. **Check Network Configurations:** * Based on the traceroute, inspect the actual configurations of the involved devices (routers, firewalls). * Look for overly permissive ACL entries, incorrect routing policies, or NAT rules that might be causing the issue. 4. **Refine the Invariant Rule:** * **Too Broad?** Is your deny rule so general that it's catching legitimate traffic that *is* correctly allowed by your network (and thus showing as a "violation" of your overly strict deny rule)? If so, make your deny rule more specific. * **Too Narrow?** Is your deny rule too specific, missing the actual pattern of traffic that's getting through? Broaden its scope or add more specific deny rules. * Adjust `source-address`, `destination-address`, `protocol`, `destination-port`, `enter-interface` etc., as needed to accurately reflect the traffic you intend to block. 5. **Adjust Network Device Configuration:** * Modify the ACLs, routing policies, or firewall rules on the actual network devices to enforce the intended denial. * Upload a new snapshot with these changes to Invariant and re-run the analysis to confirm the violation is resolved and no new issues have been introduced. ## Next Steps * Combine `deny` rules with [`critical-flow` rules](/Connectivity-Validation/Guide-Critical-Flow) to ensure that while you block unwanted traffic, essential services remain accessible. * For a more comprehensive "default-deny" or "allow-list" security posture, explore using [`deny-others` rules](/Security-Validation/Guide-Deny-Others). **Potential Improvements (Self-Correction):** * The "Start Location Inference" section could be slightly more explicit for `ingress-deny` rules, emphasizing that the `ingress-network` defines the *destination* being protected, and Invariant considers sources defined by `source-address` (or `ANY`) or `enter-interface`. *Correction made in the generated MDX above.* * A small, concrete example of a `def/networks.yaml` and `def/services.yaml` snippet alongside the basic rule structure could further clarify definition resolution. *Added implicitly by using named definitions like `INTERNAL_DB_SUBNET` and `SSH` which imply they come from `def/` files.* * The traceroute JSON example could be slightly more complete to show a few hops, but the current snippets are focused and serve their purpose. --- --- title: Connectivity Validation Overview sidebar_label: Overview --- Invariant empowers network and security teams to proactively validate network connectivity and enforce security policies using a powerful rule-based system within a digital twin environment. This ensures that critical services remain accessible and security postures are maintained, whether monitoring a live network or testing changes before deployment. At its core, Invariant's connectivity validation relies on user-defined rules that specify expected network behavior: * **Critical Flow Rules (`critical-flow`):** Assert that specific traffic *must always* be successfully delivered. Violations occur if any part of this defined flow is blocked or fails to route. * **Deny Rules (`deny`):** Assert that specific traffic *must never* be successfully delivered. Violations occur if any path allows this traffic. * **Deny-Others Rules (`deny-others`):** Assert that within a defined scope (e.g., all TCP traffic to a sensitive zone), *only explicitly permitted flows* are allowed, and all other traffic within that scope is denied. These rules are evaluated against a model of your network built from its configuration files. ## Evaluation Models: How Rules are Checked Invariant offers flexible ways to evaluate your network against these rules: ### On Upload (Installed Rules) This is the primary method for ongoing validation. 1. You define your connectivity and security rules in YAML files within the `invariant/policies/` directory of your network snapshot. 2. When you upload your snapshot using the `invariant run` command, Invariant analyzes the network model and evaluates all installed rules against it. 3. The results of this evaluation, including any violations or confirmations of policy adherence, are stored. This creates a historical record of your network's compliance status. 4. You can access these results using the `invariant show ` command. For example, `invariant show policy_violations` would list any access policy rules that failed. ```bash # Example: Run analysis on the current directory's snapshot invariant run # Example: Show violations for access policy rules invariant show policy_violations --json ``` ### Iterative Testing & Pre-Flight ("Try-Rule" Concept) While Invariant doesn't have a single command named "try-rule" for ad-hoc checks without permanent record, the same principle of testing rules or configuration changes is achieved through an iterative workflow: 1. **Local Changes:** Modify your local snapshot files. This could involve: * Editing device configurations to simulate a change. * Adding or modifying rules in your `invariant/policies/` directory. * Simulating "what-if" scenarios, such as the impact of a link failure (e.g., by commenting out an interface in a config file or, for more advanced simulations, using capabilities like Batfish's `fork_snapshot` if building custom PySDK scripts). 2. **Re-evaluate:** Run `invariant run` on this modified local snapshot. Invariant will create a new analysis record for this version. 3. **Analyze Results:** Inspect the reports as you would for a regular upload. This iterative process is fundamental for: * **Rule Development:** Testing new rules to ensure they behave as expected. * **Pre-Flight Change Validation:** Evaluating the impact of proposed network configuration changes *before* they are deployed to the live network. This could be integrated into CI/CD pipelines, as demonstrated in the [Preflight Automation Demo](/Automation). ## Enforcement Strategies: Applying Validation in Practice Invariant supports two main strategies for enforcing connectivity policies: ### Live Network Monitoring * **Process:** Regularly (e.g., hourly, daily) sync your live production network configurations into a dedicated Invariant Network (e.g., a network named "live\_production\_scans"). * **Benefit:** Invariant continuously validates your live network state against your defined policies. This provides ongoing assurance and rapid detection of unintended changes or emerging compliance issues. * **Outcome:** If violations are detected, alerts are triggered (see [Alerting](#alerting-on-violations)). The historical record of snapshots helps in tracking when a violation started and was remediated, aiding in Time To Remediation (TTR) analysis. ### Pre-Flight Change Validation * **Process:** Integrate Invariant into your change management workflow. Before any network configuration change is deployed, the proposed configurations are uploaded to Invariant (often to a separate Invariant Network or a temporary snapshot in the main network). * **Benefit:** This allows you to catch potential connectivity issues, security policy violations, or unintended side-effects of a change *before* it impacts the production environment. * **Example:** A network team works on a change in a Git feature branch. A CI/CD pipeline (like Jenkins) automatically runs `invariant run` on this branch. If Invariant detects violations, the build fails, preventing a problematic change from being merged or deployed. ## Alerting on Violations Invariant automatically generates alerts when rule violations are detected during a snapshot evaluation. * **Configuration:** Alerts are configured via **Notification Groups** in the Invariant UI (Settings > Notification Groups). You can specify email addresses to be notified for violations within specific Invariant Networks. * **Timeliness:** This ensures that relevant teams are promptly informed of issues, enabling quicker response and remediation. ## Troubleshooting Connectivity Issues with Invariant Invariant provides powerful tools for troubleshooting connectivity problems, whether they are discovered through alerts from live monitoring or during pre-flight validation. ### Initial Triage * **Alerts:** Alerts provide the first indication of an issue, typically pointing to the specific Invariant Network and snapshot where violations occurred. * **Invariant UI:** The Invariant web UI (often linked from an alert, conceptually) provides a quick overview of the failing snapshot, the rules that were violated, and often direct links to example traceroutes for those violations. ### Detailed Analysis with CLI Reports For in-depth investigation, the Invariant CLI is invaluable: * **Violation Details:** Reports like `critical_flows_details` (for critical flow rule failures) and `policy_details` (for access policy violations) provide concrete examples of violating traffic flows. ```bash invariant show critical_flows_details --json invariant show policy_details --json ``` * **Virtual Traceroutes:** These reports include detailed virtual traceroutes. Unlike traditional traceroutes, Invariant's traces show: * The hop-by-hop path of the example packet. * Routing decisions made at each hop. * Evaluation against ACLs and firewall rules encountered along the path. * The final disposition of the packet (e.g., `ACCEPTED`, `DENIED_IN`, `NO_ROUTE`). ### Historical Investigation If an issue is detected in the live network, you can use Invariant's snapshot history to determine when it began: * **List Snapshots:** Use `invariant snapshots` to view a list of past evaluations with timestamps. ```bash invariant snapshots --network live_production_scans --tsv ``` * **Inspect Historical Reports:** Use the snapshot UUID with `invariant show --snapshot ...` to retrieve reports (e.g., `policy_violations`) from a specific point in time. This helps pinpoint when a violation was first introduced. ### Root Cause Analysis Invariant aids in root cause analysis, especially when the reason for a failure isn't immediately obvious: * **Comparing Snapshots:** If a change introduced an issue, you can compare various reports (e.g., `routes`, `bgp_session_status`, `interfaces`, `ipsec_edges`) between the problematic snapshot and a known-good (e.g., "golden") snapshot. Diffing the JSON or TSV outputs of these reports can highlight specific configuration or state changes that led to the problem. ```bash # Example: Diffing route tables invariant show routes --snapshot --json > bad_routes.json invariant show routes --snapshot --json > good_routes.json diff good_routes.json bad_routes.json ``` * **Testing Hypotheses Safely:** If you suspect a particular configuration change or failure caused an incident, you can: 1. Modify a local copy of your network snapshot to reflect your hypothesis (e.g., revert a specific config line, comment out an interface to simulate a link down, change an ACL). 2. Run `invariant run` on this experimental snapshot. 3. Observe if the original issue is resolved or reproduced. This allows you to confirm or deny potential causes in a safe, offline digital twin environment without impacting the live network. By leveraging these capabilities, Invariant provides a comprehensive framework for validating network connectivity, enforcing security policies, and efficiently troubleshooting issues. --- --- title: "Guide: critical-flow rules" --- Critical-flow rules in Invariant are designed to assert that specific, essential network traffic **must always be successfully delivered**. Unlike simply checking for a single path, Invariant exhaustively analyzes your network's digital twin to find any scenario—be it routing configurations, ACLs, or firewall policies—that could prevent this critical traffic from reaching its destination. This provides a strong guarantee for the reachability of your vital services. ### How Invariant Evaluates Critical Flow Rules The evaluation process involves several key steps: 1. **Digital Twin Creation**: Invariant, leveraging Batfish, constructs a detailed model of your network from the provided configuration files. 2. **Definition Resolution**: Any named networks (e.g., `DATABASE_SERVERS`), services (e.g., `HTTPS`), or locations (e.g., `DMZ_ENTRY_POINTS`) used in your rule are resolved to their concrete IP addresses, ports, and interfaces. 3. **Start Location Inference**: * For `egress-critical-flow` rules, if `source-interface` or `enter-interface` is not explicitly defined, Invariant intelligently infers potential starting interfaces based on the `source-address`. * For `ingress-critical-flow` rules, the `ingress-network` definition implicitly defines the destination, and Invariant searches for flows from any valid source towards it. 4. **Exhaustive Flow Search**: Invariant performs a comprehensive search for all possible packets that match your critical flow definition. It looks for any instance where such a packet could be dropped, denied, or misrouted. 5. **Outcome**: * If **any** packet defined by the rule fails to be delivered via **any** possible path, the critical-flow rule is marked as a violation. * If **all** packets defined by the rule can be successfully delivered across all potential paths, the rule passes. ### Defining Critical Flow Rules Critical flow rules are defined within an `access-policy` block in your `invariant/policies/` YAML files. Key characteristics and fields: * **`type`**: Must be either `ingress-critical-flow` (for traffic destined *to* the policy's `ingress-network`) or `egress-critical-flow` (for traffic originating *from* the policy's `egress-network`). * **Traffic Specification**: Uses fields like `protocol`, `source-address`, `destination-address`, `source-port`, `destination-port` to define the traffic. * **Interface Specificity (Optional)**: * `enter-interface`: For `egress-critical-flow`, specifies that traffic must originate by entering these specific interfaces (useful for testing traffic from external sources or specific network segments). * `source-interface`: For `egress-critical-flow`, specifies that traffic must originate *from* these specific interfaces (using their configured IPs). **Example `ingress-critical-flow`:** This rule asserts that any host should be able to reach the `DNS_SERVERS` network on UDP port 53. ```yaml access-policy: - name: core-dns-reachability comment: Ensure DNS servers are reachable owner: netops@example.com ingress-network: DNS_SERVERS # Target network for ingress rules: - type: ingress-critical-flow comment: All internal networks must reach DNS source-address: RFC1918 # From any internal IP destination-port: DNS # Standard DNS service protocol: udp ``` **Example `egress-critical-flow`:** This rule asserts that hosts in `APP_SERVERS_VLAN` must be able to connect to `DATABASE_SERVERS` on TCP port 1433. ```yaml access-policy: - name: app-to-db-connectivity comment: Critical application to database flow owner: app-team@example.com egress-network: APP_SERVERS_VLAN # Source network for egress rules: - type: egress-critical-flow comment: App servers must reach database servers on SQL port destination-address: DATABASE_SERVERS destination-port: MSSQL_TCP # Assuming MSSQL_TCP is defined as TCP/1433 protocol: tcp ``` ### Interpreting Results After an `invariant run`, you'll primarily look at these reports: * `critical_flows_ok`: Lists all critical flow rules that passed. * `critical_flows_violations`: Lists all *enforced* critical flow rules that failed. * `critical_flows_violations_unenforced`: Lists failing critical flow rules that were marked with `enforce: false`. * `critical_flows_details`: This is the most crucial report for debugging. It provides example virtual traceroutes for both passing and failing rules, showing *why* a flow succeeded or failed. ### Strategic Application * **Core Services**: Ensure core network services like DNS, NTP, and authentication servers are always reachable. * **Application Connectivity**: Validate critical application-to-application or application-to-database communication paths. * **Broad vs. Narrow Rules**: * **Broad rules** (e.g., "any internal user to any web server on HTTPS") provide wide coverage but can be harder to debug if they fail due to the many potential paths and policies involved. * **Narrow/Canary rules** (e.g., "specific_critical_server_A to specific_critical_server_B on specific_port") are easier to pinpoint failures for and are excellent for high-priority services. * **Complement Deny Rules**: Critical flow rules ensure what *must* work, while `deny` or `deny-others` rules ensure what *must not* work, providing a comprehensive security and connectivity posture. ## Understanding Traceroutes Invariant's virtual traceroutes provide a deep, hop-by-hop analysis of how packets traverse your network model. This is far more detailed than a live traceroute. ### Accessing Traceroutes: The `critical_flows_details` Report The `critical_flows_details` report is your primary tool for understanding the behavior of critical flow rules. Each row in this report corresponds to a specific check or an example flow Invariant analyzed for one of your rules. Key fields in `critical_flows_details`: * **`flow` / `flow_str`**: Describes the specific example packet (source/destination IPs, ports, protocol, etc.) that was traced. * **`traces`**: An array containing one or more trace paths. Multiple paths can exist if Equal-Cost Multi-Path (ECMP) routing is in play. * **`disposition` (within each trace)**: The final outcome for that specific path (e.g., `ACCEPTED`, `DENIED_IN`, `NO_ROUTE`). ### Decoding a Trace Each trace within the `traces` array is a list of `hops`. Each `hop` represents a device (router, firewall, switch) in the packet's path. Each `hop` contains a list of `steps`, detailing the packet's processing on that device: * **`RECEIVED(Interface)`**: Indicates the interface on which the packet arrived at the current hop. * *Example*: `{"action": "RECEIVED", "detail": {"inputInterface": "GigabitEthernet0/0"}}` * **`PERMITTED(FilterName (FilterType))`**: The packet was allowed by the specified ACL or firewall rule (`FilterName`) applied at a particular stage (`FilterType`, e.g., `INGRESS_FILTER`). * *Example*: `{"action": "PERMITTED", "detail": {"filter": "acl_allow_ssh (INGRESS_FILTER)"}}` * **`DENIED(FilterName (FilterType))`**: The packet was blocked by the specified filter. **This is a common reason for critical flow rule violations.** The trace ends here for this path. * *Example*: `{"action": "DENIED", "detail": {"filter": "acl_block_all (EGRESS_FILTER)"}}` * **`FORWARDED(Forwarded out interface: ..., Routes: [...])`**: A routing decision was made. * `outputInterface`: The interface the packet will be sent out of. * `resolvedNexthopIp`: The next-hop IP address. * `routes`: A list of routes from the RIB that matched the packet's destination. * *Example*: `{"action": "FORWARDED", "detail": {"outputInterface": "Serial0/0", "resolvedNexthopIp": "10.1.1.2", "routes": [{"protocol": "ospf", "network": "0.0.0.0/0", ...}]}}` * **`NO_ROUTE(Discarded)`**: No route was found in the RIB for the packet's destination. The packet is dropped. **This is another common reason for critical flow violations.** * *Example*: `{"action": "NO_ROUTE", "detail": {"type": "Discarded"}}` * **`NEIGHBOR_UNREACHABLE(Discarded)`**: The next-hop IP address was unresolvable (e.g., ARP or ND failure in the model). Packet dropped. * **`ACCEPTED(Interface)`**: The packet was delivered to an interface on the device itself (e.g., destined for a loopback IP, or a service running on the router). This is a successful disposition. * **`DELIVERED_TO_SUBNET(Output Interface: ..., Resolved Next Hop IP: ...)`**: The packet was successfully forwarded to the directly connected subnet of the destination IP. This is a successful disposition. * **`EXITS_NETWORK(Output Interface: ..., Resolved Next Hop IP: ...)`**: The packet was forwarded out of an interface that leads to a network segment not modeled by Invariant (e.g., towards the internet via an ISP link). This is generally a successful disposition if the destination is external. ### Analyzing Traces for Critical Flows * **Passing Rule**: For a rule in `critical_flows_ok`, the `traces` in `critical_flows_details` will show paths ending in a successful disposition like `ACCEPTED`, `DELIVERED_TO_SUBNET`, or `EXITS_NETWORK` (if appropriate). * **Failing Rule**: For a rule in `critical_flows_violations`, the `traces` will show the exact hop and step where the failure occurred (e.g., a `DENIED` step by an ACL, or a `NO_ROUTE` step). ### Example: Interpreting a `critical_flows_details` Snippet Let's consider a simple critical flow rule: ```yaml # Invariant/policies/example.yaml access-policy: - name: web-server-access owner: web-team@example.com ingress-network: WEB_SERVER_SUBNET rules: - type: ingress-critical-flow comment: Ensure internal users can access web server via HTTPS source-address: INTERNAL_USERS_SUBNET destination-port: HTTPS protocol: tcp ``` **Scenario 1: Passing Rule** A snippet from `critical_flows_details` (in JSON) for a passing flow might look like: ```json { "flow_str": "tcp src_ip=192.168.1.50 dst_ip=10.10.10.100 dst_port=443", "traces": [ { "disposition": "DELIVERED_TO_SUBNET", "hops": [ // ... initial hops ... { "node": "core-switch-01", "steps": [ {"action": "RECEIVED", "detail": {"inputInterface": "GigabitEthernet1/0/1"}}, {"action": "PERMITTED", "detail": {"filter": "ALLOW_INTERNAL_ACCESS (INGRESS_FILTER)"}}, {"action": "FORWARDED", "detail": {"outputInterface": "GigabitEthernet1/0/24", "resolvedNexthopIp": "10.10.10.100", "routes": [{"protocol": "connected", "network": "10.10.10.0/24", ...}]}}, {"action": "TRANSMITTED", "detail": {"outputInterface": "GigabitEthernet1/0/24"}} ] }, { "node": "web-server-01.example.com", // Assuming host modeling "steps": [ {"action": "RECEIVED", "detail": {"inputInterface": "eth0"}}, {"action": "ACCEPTED", "detail": {"interface": "eth0"}} // Delivered to host ] } ] } // ... potentially other successful paths if ECMP exists ... ] } ``` This trace shows traffic from `192.168.1.50` (part of `INTERNAL_USERS_SUBNET`) successfully reaching `10.10.10.100` (part of `WEB_SERVER_SUBNET`) on port 443. It was permitted by the `ALLOW_INTERNAL_ACCESS` filter on `core-switch-01` and finally `ACCEPTED` by the web server. **Scenario 2: Failing Rule (ACL Denial)** A snippet for a failing flow, for instance, if an ACL unexpectedly blocks the traffic: ```json { "flow_str": "tcp src_ip=192.168.1.50 dst_ip=10.10.10.100 dst_port=443", "traces": [ { "disposition": "DENIED_IN", "hops": [ // ... initial hops ... { "node": "firewall-01", "steps": [ {"action": "RECEIVED", "detail": {"inputInterface": "inside_interface"}}, {"action": "DENIED", "detail": {"filter": "BLOCK_UNTRUSTED_HTTPS (INGRESS_FILTER)"}} // Failure point ] } ] } ] } ``` In this case, the traffic was `DENIED` by the filter `BLOCK_UNTRUSTED_HTTPS` on `firewall-01`. This immediately tells you where to investigate the misconfiguration. ### Edge Case: No Traceroute Generated Occasionally, a critical flow rule might fail, but `critical_flows_details` might not show a full traceroute, or the trace might be very short (e.g., only showing the origin node with a `NO_ROUTE` disposition). This typically means: * **No Route at Origin**: The starting device/location for the flow doesn't even have a route towards the destination. The packet can't begin its journey. * **Misconfigured Start Location**: The `source-address`, `enter-interface`, or `source-interface` in your rule might not resolve to any valid points in your network model from which the flow could realistically start. Carefully examine the `flow` details and the initial hops (if any) to diagnose such issues. --- --- id: networks title: "Network Management" description: "Learn how to create, edit, and delete Networks in Invariant Technology. Networks are containers for snapshots of your actual network configurations." date: 2025-05-19 lastmod: 2025-05-19 tags: ["networks", "snapshots", "configuration", "settings"] sidebar_label: Networks sidebar_position: 1 --- ## Overview Invariant Networks organize your network configuration snapshots, enabling you to track changes over time, understand network evolution, and identify issues. ### Creating a New Network Use these steps to create a new Invariant Network for tracking snapshots. 1. From **Invariant Settings**, click **Add Network**. 2. In the form that appears: * Fill in the **Name** field. * Optionally, add a **Description**. 3. Click **Create Network**. 4. You will see a "Network successfully created" confirmation. Animated UI walkthrough ### Editing an Existing Network Use these steps to modify the configuration details of an existing Invariant Network. 1. From **Invariant Settings**, click the name of the Network you wish to edit. 2. In the submenu that appears, update the fields with your new information. 3. Click the **Save** button to apply your changes. Animated UI walkthrough ### Deleting a Network > **Caution:** Deleting a Network is a permanent action. It will also remove all associated snapshots (historical network configs) and cannot be undone. 1. From **Invariant Settings**, click the name of the Network you wish to delete. 2. In the Network's submenu that appears, click the **Delete Network** button. 3. On the confirmation prompt, click **Confirm Delete** to permanently remove the Network and its snapshots. Animated UI walkthrough --- --- id: notification_groups title: "Notification Group Management" description: "Configure Notification Groups in Invariant Technology to send email alerts for events on specific Networks to designated subscribers." date: 2025-05-19 lastmod: 2025-05-19 tags: ["notifications", "email", "alerts", "automation"] sidebar_label: Notification Groups sidebar_position: 2 --- ## Overview Invariant Notification Groups allow you to define named collections of email subscribers. These groups can be subscribed to specific Networks. When events occur on those subscribed Networks, an email notification is automatically sent to all subscribers in the group. A description can be added for clarity. ### Creating a Notification Group Use these steps to create a new Notification Group. 1. From **Invariant Settings**, click the **Add Notification Group** button. * A form for defining the new group will appear. 2. Enter a unique **Group Name** in the designated field. 3. **Add Email Subscribers:** * Click the **Add Email** button. * In the new text box that appears, enter the subscriber's email address. * To add more email addresses, repeat the "Click **Add Email** and enter email" steps for each subscriber. 4. **Subscribe to Networks:** * In the list of available Networks, check the box next to each Network you want this group to receive notifications for. 5. (Optional) Provide a **Description** for the group in the text field. 6. Click **Create Notification Group** to save the new group and its settings. * The confirmation message "Notification Group successfully created" should appear. Animated UI walkthrough ### Editing a Notification Group Use these steps to modify an existing Notification Group's name, subscribers, network subscriptions, or description. 1. From **Invariant Settings**, click the name of the Notification Group you wish to edit. * This will display the group's details and available actions. 2. Click the **Edit Notification Group** button. * The group's settings will become editable, similar to the creation form. 3. **Modify the Group Settings as needed:** * Update the **Group Name**. * Manage **Email Subscribers**: * To add a new subscriber, click **Add Email** and enter the email address. * To remove an existing subscriber, typically there will be a remove icon (e.g., an 'X' or 'trash can') next to their email. * Adjust **Network Subscriptions** by checking or unchecking the boxes next to Network names. * Edit the **Description**. 4. Once you have finished making changes, click the **Save** button to apply them. Animated UI walkthrough ### Deleting a Notification Group > **Caution:** Deleting a Notification Group is a permanent action and cannot be undone. This will remove the group and its list of subscribers and network associations. 1. From **Invariant Settings**, click the name of the Notification Group you wish to delete. 2. In the group's options or submenu that appears, click the **Delete Notification Group** button. 3. On the confirmation prompt, click **Confirm Delete** to permanently remove the Notification Group. Animated UI walkthrough --- --- id: monitor_targets title: "Monitor Targets for GitHub Repositories" description: "Configure Monitor Targets to watch specific paths within your connected GitHub repositories and link them to Invariant Networks for automatic snapshot updates." date: 2025-05-19 # Date of creation or last major update lastmod: {{YYYY-MM-DD}} # Date of last modification tags: ["monitor targets", "github", "automation"] category: "Integrations" sidebar_label: Monitor Targets sidebar_position: 3 --- ## Monitor Targets for GitHub Repositories Monitor Targets in Invariant Technology allow you to precisely define which parts of a connected GitHub repository should be monitored for changes. Each Monitor Target links a specific path (or the entire repository) to an Invariant Network, ensuring that commits affecting that path automatically trigger snapshot updates for the designated Network. ### Creating a New Monitor Target 1. From **Invariant Settings**, navigate to the **Monitor Targets** section. 2. Click the **Add Monitor Target** button. * A form for defining the new Monitor Target will appear. 3. In the form, configure the following: * **Name:** Enter a descriptive name for this Monitor Target. * **Repository:** Select the connected GitHub Repository from the dropdown list. * **Path (Optional):** Specify the exact path within the selected repository to monitor (e.g., `configs/`). If left blank, the entire repository will be monitored. * **Invariant Network:** Select the Invariant Network to which snapshots from this path should be associated. * **Description (Optional):** Add a free-form text description for more context. 4. Click the **Create Monitor Target** button (or **Save**) to finalize the setup. * A confirmation message should appear, and the new Monitor Target will be listed. Animated UI walkthrough ### Editing a Monitor Target 1. From **Invariant Settings**, navigate to the **Monitor Targets** section. 2. In the list of Monitor Targets, click on the **Name** of the target you wish to edit. * This will typically take you to a details page or open an edit view for that target. 3. Click the **Edit Monitor Target** button. 4. Modify any of the available fields as needed. 5. Once you have finished making changes, click the **Save** button to apply them. * A confirmation message like "Monitor Target successfully updated" should appear. Animated UI walkthrough ### Deleting a Monitor Target > **Caution:** Deleting a Monitor Target will stop Invariant Technology from monitoring the specified path in the GitHub repository for the linked Invariant Network. Automatic snapshot updates for that specific target will cease. This action cannot be undone, but you can create a new Monitor Target if needed. 1. From **Invariant Settings**, navigate to the **Monitor Targets** section. 2. In the list of Monitor Targets, click on the **Name** of the target you wish to delete. 3. In the target's details, click the **Delete Monitor Target** button. 4. On the confirmation prompt, click **Confirm Delete** (or **Confirm**) to permanently remove the Monitor Target. 5. Animated UI walkthrough --- --- id: github title: "GitHub Repositories Integration" description: "Learn how to connect GitHub repositories to Invariant Technology for automatic snapshot uploads and manage existing connections." date: 2025-05-19 lastmod: 2025-05-19 tags: ["github", "repositories", "automation"] sidebar_label: Git Repositories sidebar_position: 4 --- ## GitHub Repositories Integration Invariant Technology allows you to connect your GitHub repositories to automatically upload network configuration snapshots when changes are committed. This integration streamlines the process of keeping your Invariant snapshots in sync with your version-controlled configurations. ### Connecting a GitHub Repository 1. From **Invariant Settings**, navigate to the **Github Repositories** section. 2. Click the **Connect a GitHub Repository** button (or a similarly named link/button). * You will be redirected to GitHub to authorize access and select repositories. 3. **On the GitHub platform:** * Follow the prompts to authorize Invariant Technology. * Select the specific repository or repositories you wish Invariant to access. You may need to specify if you are connecting to a personal account repository or one within an organization. * Once you have made your selections, click **Install & Authorize**, or a similar confirmation button provided by GitHub. * You should then be redirected back to Invariant Technology. 4. **Back in Invariant Technology**, on the **Github Repositories** page: * The newly connected repository (or repositories) should appear in the list. * Allow a few moments for the connection to fully establish. The **Status** for the repository should update to "OK" (or a similar indicator of a successful connection, e.g., "Connected," "Active"). * If the status does not update automatically, you can click a **Refresh** button (or a refresh icon) on the page to check the current connection status. Animated UI walkthrough --- --- id: api_tokens title: "API Token Management" description: "Learn how to create and delete API Tokens for programmatic access to Invariant Technology features and data." date: 2025-05-19 lastmod: 2025-05-19 tags: ["api", "tokens", "security", "programmatic access", "authentication", "settings", "automation"] sidebar_label: API Tokens sidebar_position: 5 --- ## Overview API Tokens allow programmatic access to Invariant Technology features and data. ### Creating an API Token > **Important Security Notice:** > When you create an API Token, the token value will be displayed **only once**. You must copy and securely store this token immediately. If you lose the token or navigate away before copying it, you will need to generate a new one. 1. From **Invariant Settings**, click the **Create API Token** button. * A form for defining the new API token will appear. 2. In the form: * Enter a descriptive **Name** for the token (e.g., "Jenkins Integration," "Backup Script"). * (Optional) Provide a **Description** for further context about its intended use. 3. Click the **Create API Token** button on the form. 4. **Your new API Token will now be displayed on the screen.** * **Immediately copy this token value.** * Store it in a secure password manager or a safe location. **It will not be shown again.** 5. Once you have securely recorded the token, you can close any confirmation dialogs or navigate away from the page. Animated UI walkthrough ### Deleting an API Token > **Note:** Deleting an API Token will immediately revoke its access. Any applications or scripts using this token will no longer be able to authenticate with Invariant Technology. This action cannot be undone, but you can always create a new token if needed. 1. From **Invariant Settings**, locate the list of your existing API Tokens. 2. Select the token(s) you wish to delete by clicking the checkbox next to each token's **Name**. 3. Once selected, click the **Delete Token** button. 4. On the confirmation pop-up menu, click **Confirm** to permanently delete the selected API Token(s). Animated UI walkthrough --- --- id: users title: "User Management" description: "Instructions for inviting new users to Invariant Technology and deleting existing user accounts." date: 2025-05-19 lastmod: 2025-05-19 tags: ["users", "administration", "access control"] sidebar_label: Users Management sidebar_position: 6 --- ## User Management Manage user access to Invariant Technology. ### Inviting a New User This process involves an administrator initiating the invitation and the invited individual completing the setup. **Administrator Actions:** 1. From **Invariant Settings**, navigate to the user management section and click the **Invite External User** button (or a similarly named option like "Add Managed User"). 2. In the field provided, enter the email address of the person you wish to invite. 3. Click the **Create User** button (or equivalent like "Invite"). * An invitation email will be sent to the provided email address. Animated UI walkthrough **Invited User Actions (To be performed by the recipient):** 1. The invited person must open the invitation email received from Invariant Technology. 2. In the email, click the provided link to accept the invitation. 3. Follow the on-screen prompts to set up their account, which will include creating a secure password. 4. Once they complete these steps, their user account in Invariant Technology will be created and active. ### Deleting a User > **Caution:** Deleting a user account is a permanent action and will revoke their access to Invariant Technology. Consider any implications for data or configurations they might own or manage. 1. From **Invariant Settings**, navigate to the user management section where users are listed. 2. Click on the **Name** of the user account you wish to delete (or an associated 'manage'/'edit' icon). 3. In the user's details or options menu, click the **Delete User** button. 4. On the confirmation prompt, click **Confirm Delete** to permanently remove the user's account. Animated UI walkthrough --- --- id: security title: "Workspace Security Settings" description: "Understand and configure security settings for your Invariant Technology workspace, including default login methods and collaboration policies for domain-managed users and external collaborators." date: 2025-05-19 lastmod: 2025-05-19 tags: ["security"] sidebar_label: Security Settings sidebar_position: 7 --- ## Workspace Security Settings If your Invariant Technology workspace owns a domain (e.g., yourcompany.invariant.tech), you can configure specific security settings to manage how users access your workspace and collaborate. These settings are typically found within the **Invariant Settings** area under a "Security" or "Domain Settings" section. Below are the different options available and their descriptions: * **Default Login Settings:** * **Options:** * **OpenID Connect providers:** Set OIDC as the default, requiring users to authenticate via your configured identity provider. * **Passwords:** Set traditional username and password authentication as allowed. * **Allow Managed Users to Join Other Workspaces:** * **Description:** This setting determines whether users who are part of your managed domain (e.g., user@yourcompany.tech) are permitted to accept invitations to and join other Invariant Technology workspaces (which might belong to different organizations or domains). * **Impact:** * **Yes:** Your domain users can collaborate in other Invariant workspaces. * **No:** Your domain users are restricted to your own workspace, preventing them from joining external Invariant environments. Animated UI walkthrough * **Allow New External Collaborators:** * **Description:** This toggle controls whether new users from external domains (i.e., those not managed by your organization and not using an @yourcompany.invariant.tech email) can be invited to and join your workspace. * **Impact:** * **Yes:** You can invite and onboard new collaborators from any domain. * **No:** New invitations cannot be sent to users outside your managed domain. * **Important Note:** This setting **does not affect existing external collaborators**. Users from external domains who are already members of your workspace will retain their access regardless of this setting. It only applies to *new* invitations and attempts to join. Animated UI walkthrough --- --- title: "Configuring an Identity Provider (OIDC)" description: "Learn how to integrate an OpenID Connect (OIDC) Identity Provider with Invariant Technology to enable single sign-on (SSO) for your workspace users." date: 2025-05-19 lastmod: 2025-05-19 tags: ["identity provider", "oidc", "sso", "authentication", "security", "settings"] sidebar_label: Identity Providers (OIDC) sidebar_position: 8 --- ## Configuring an Identity Provider (OIDC) Integrating an OpenID Connect (OIDC) Identity Provider (IdP) with Invariant Technology allows you to enable Single Sign-On (SSO) for your workspace. This centralizes user authentication through your existing IdP (e.g., Okta, Azure AD, Auth0), enhancing security and simplifying the login process for your users. > **Prerequisite:** Before you begin, you must have an application configured within your chosen Identity Provider specifically for Invariant Technology. From this IdP application configuration, you will need the following details: > * **Client ID** > * **Client Secret** > * **Provider Discovery URI** (also known as OpenID Configuration URL, Discovery Endpoint, or `.well-known/openid-configuration` URL) ### Adding an OpenID Connect (OIDC) Provider 1. From **Invariant Settings**, navigate to the **Identity Provider** section (this might also be labeled "SSO," "OIDC Configuration," or similar). 2. Click the **Add OpenID Connect provider** button. * A form for entering your IdP details will appear. 3. In the form, provide the following information obtained from your Identity Provider's application configuration: * **Custom Name:** Enter a descriptive name for this IdP connection (e.g., "Okta Production," "Azure AD SSO"). This name is for your reference within Invariant Technology. * **Client ID:** Enter the Client ID. * **Client Secret:** Enter the Client Secret. * **Note:** Treat the Client Secret like a password; it is sensitive information. * **Provider Discovery URI:** Enter the full Discovery URI. 4. Once all fields are correctly filled, click the **Add Integration** button (or **Save Configuration**, **Connect**). * Invariant Technology will attempt to connect to your IdP using the provided details. * Upon successful configuration, the IdP will be listed, and you may be able to set it as the default login method (refer to "Workspace Security Settings" for more details). Animated UI walkthrough --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- id: overview title: "Overview: Identity and Access in Invariant" description: "Understand the fundamental concepts of user identity and access within Invariant Technology, including managed users and external collaborators." date: 2025-05-19 lastmod: 2025-05-19 tags: ["user management", "identity", "access", "concepts"] category: "User Management Concepts" sidebar_label: Overview sidebar_position: 1 --- # Overview: Identity and Access in Invariant Technology Effective user management is fundamental to maintaining a secure and productive Invariant Technology workspace. It's about defining who has access and how they prove their identity. At its heart, user management in Invariant revolves around **identity** and **access**. * **Identity:** Every individual interacting with your Invariant workspace needs a unique digital identity. This identity is typically associated with an email address and allows Invariant to distinguish one user from another. Users can be categorized broadly: * **Managed Users (Domain Users):** Individuals whose accounts are tied to a domain that your Invariant workspace "owns" or manages (e.g., `user@yourcompany.invariant.tech`). Their lifecycle and some behaviors can be more tightly controlled by workspace settings. * **External Collaborators:** Users from outside your managed domain (e.g., `consultant@externaldomain.com`) who are invited to collaborate within your workspace. * **Authentication:** This is the process by which users prove they are who they claim to be. Invariant supports different authentication methods, which we'll discuss further, to validate a user's credentials before granting access. * **Authorization (Access Control):** Once a user is authenticated, authorization determines what specific resources, features, or data they can access and what actions they can perform. While this guide focuses on identity and authentication, it's important to remember that roles and permissions are the next layer in controlling user capabilities. The lifecycle of a user typically involves: 1. **Invitation/Creation:** A new user is introduced to the system. 2. **Activation/Onboarding:** The user confirms their identity and sets up their credentials. 3. **Active Use:** The user accesses and utilizes Invariant according to their permissions. 4. **Deactivation/Deletion:** The user's access is revoked. Understanding these fundamental aspects helps in making informed decisions about how to configure and manage your user base effectively. --- --- id: oidc title: "The Role of OIDC in User Authentication" description: "Explore how OpenID Connect (OIDC) enhances user authentication in Invariant Technology through Single Sign-On (SSO) and centralized identity management." date: 2025-05-19 lastmod: 2025-05-19 tags: ["user management", "oidc", "sso", "authentication", "identity provider", "security", "concepts"] category: "User Management Concepts" sidebar_position: 2 --- # The Role of OIDC (OpenID Connect) in User Authentication OpenID Connect (OIDC) is a modern authentication protocol built on top of OAuth 2.0. Integrating Invariant Technology with an OIDC-compliant Identity Provider (IdP) like Okta, Azure AD, Auth0, or others, offers significant advantages for user management and security. **Why Use OIDC with Invariant?** * **Single Sign-On (SSO):** Users can log in to Invariant using the same credentials they use for other corporate applications connected to your IdP. This simplifies the user experience (fewer passwords to remember) and reduces password fatigue. * **Centralized Identity Management:** User identities are managed by your organization's central IdP. This means: * **Consistent Policies:** Password complexity, multi-factor authentication (MFA), and account lockout policies are enforced by your IdP, ensuring consistency across applications. * **Simplified Onboarding/Offboarding:** When an employee joins or leaves your organization, their access to Invariant (and other connected applications) can be managed centrally through the IdP. Disabling an account in the IdP typically revokes access everywhere. * **Enhanced Security:** * Leverages the robust security features of your IdP (e.g., MFA, conditional access policies). * Reduces the risk associated with users managing separate, potentially weaker, passwords for Invariant. * Reduces Invariant's direct involvement in password storage and management for those users. **How OIDC Changes the Login Experience:** When OIDC is configured and set as a login method: 1. A user attempting to log into Invariant is redirected to your IdP's login page. 2. The user authenticates with their IdP credentials (and MFA, if configured). 3. Upon successful authentication, the IdP redirects the user back to Invariant, asserting their identity. 4. Invariant grants access based on this validated identity. For users authenticating via OIDC, Invariant's native password policies become less relevant, as password management is handled by the external IdP. Understanding OIDC is key to leveraging modern, secure authentication within your Invariant workspace. ====== Invariant provides Single Sign-On (SSO) via OIDC functionality for customers to access the app through a single authentication source. This allows IT administrators to better manage team access and keeps information more secure. # What is SSO? # Who can use SSO? # Setup SSO Step-by-Step Instructions: Step 1: Navigate to the login page and select the "Login with [Identity Provider]" option. Step 2: You will be redirected to the identity provider's login page. Enter your credentials (e.g., email and password). Step 3: If multi-factor authentication (MFA) is enabled, complete the additional verification steps. Step 4: Review and consent to any requested permissions (e.g., access to your email or profile information). Step 5: After successful authentication, you will be redirected back to the application and logged in. Troubleshooting Tips: What to do if login fails (e.g., check credentials, ensure MFA is set up correctly). How to handle issues with permissions or consent. Security Notes: Emphasize the importance of using a trusted identity provider. Highlight the use of secure tokens for session management. Visual Aids: # How do I reset my password with OIDC? --- --- id: security_policies title: "Impact of Workspace Security Policies on Users" description: "Understand how Invariant Technology's workspace security policies, such as login settings and collaborator permissions, affect user access and collaboration." date: 2025-05-19 lastmod: 2025-05-19 tags: ["user management", "security policies", "collaboration", "login settings", "domain users", "external users", "concepts"] category: "User Management Concepts" sidebar_position: 3 --- # Impact of Workspace Security Policies on Users Invariant Technology provides several workspace-level security policies that directly influence user access, collaboration, and the overall security posture. These settings are particularly impactful when your workspace owns a domain. Understanding their effects is key to tailoring Invariant to your organization's needs. ### Default Login Settings * **What it controls:** The primary method(s) users employ to sign in and whether traditional password-based login is permitted. * **Impact on Users:** * **Setting OIDC as Default:** When users navigate to the Invariant login page, they might be immediately directed to your OIDC provider or see it as the primary option. This streamlines the SSO experience. * **Disabling Password Sign-In:** * **Effect:** This is a significant security enhancement. If enabled, users *cannot* log in using an Invariant-specific password. They *must* authenticate via OIDC. * **User Experience:** Users who previously used passwords will need to use the OIDC flow. New users will only have the OIDC option. This ensures all access (for domain users) is channeled through your centrally managed IdP. * **Consideration:** Ensure your OIDC integration is fully functional and all relevant users are provisioned in your IdP before disabling password sign-in to avoid locking users out. ### Allow Managed Users to Join Other Workspaces * **What it controls:** Whether users belonging to your managed Invariant domain (e.g., `user@yourcompany.invariant.tech`) can be members of Invariant workspaces outside your own organization's control. * **Impact on Users:** * **If Allowed:** Your users have the flexibility to collaborate with external partners or join other Invariant instances if invited. This can be beneficial for cross-organizational projects. * **If Disallowed:** This restricts your domain users solely to your organization's Invariant workspace(s). * **Security Benefit:** It provides tighter control over where your employees are active and potentially accessing or sharing data via Invariant. * **User Experience:** Users from your domain will be unable to accept invitations to external Invariant workspaces, which might limit their collaboration capabilities if such external access is needed. ### Allow New External Collaborators * **What it controls:** Whether new users from *outside* your managed domain can be invited to join *your* workspace. * **Impact on Users and Collaboration:** * **If Allowed:** Your administrators and users (depending on their permissions) can invite external parties (consultants, partners, clients) to collaborate within your Invariant workspace. This fosters broader collaboration. * **If Disallowed:** * **Security Benefit:** This significantly restricts the ability to bring in external individuals, potentially reducing the risk of unauthorized access or data exposure through third parties. Your workspace becomes more insular. * **User Experience/Collaboration:** It will prevent the onboarding of new external collaborators. If you need to work with external entities within Invariant, this setting would need to be enabled (at least temporarily, if your policy is strict). * **Key Clarification:** This setting only affects *new* external invitations. Existing external collaborators who are already members of your workspace will *retain their access* even if you disallow new ones. It's about controlling future external additions, not retroactively removing current ones. By carefully configuring these security policies, administrators can strike the right balance between security, control, and collaborative flexibility for their Invariant Technology workspace users. --- --- id: invitation title: "Understanding the User Invitation Process" description: "Explore how user invitations work in Invariant Technology, from initiation by an administrator to acceptance and account activation by the invited user." date: 2025-05-19 lastmod: 2025-05-19 tags: ["user management", "invitations", "onboarding", "user lifecycle", "concepts", "explanation"] category: "User Management Concepts" sidebar_position: 4 --- # Understanding the User Invitation Process in Invariant Inviting users is the primary way to bring new individuals into your Invariant Technology workspace. This process is designed to be secure and straightforward, involving distinct steps for both the administrator issuing the invitation and the recipient. Understanding this flow helps ensure a smooth onboarding experience. ## The Lifecycle of an Invitation An invitation typically goes through several stages: 1. **Initiation (by Administrator):** * An administrator with the appropriate permissions navigates to the user management section within Invariant Settings. * They select an option like "**Invite External User**" or "**Add User**." * The administrator provides the email address of the individual they wish to invite. * Upon submission, Invariant Technology generates a unique invitation and sends it to the specified email address. 2. **Pending (Invitation Sent):** * Once the email is sent, the invitation is in a "pending" state. * The system may track these pending invitations, allowing administrators to see who has been invited but has not yet accepted. * The invitation email contains a unique link that the recipient must use to proceed. 3. **Acceptance (by Invited User):** * The invited individual receives the email from Invariant Technology. * They must click the unique link within the email. This action signifies their intent to accept the invitation. * **Security Note:** Invitation links are typically designed for one-time use by the intended recipient to prevent unauthorized access. 4. **Account Setup & Activation (by Invited User):** * Upon clicking the invitation link, the user is usually directed to a page where they complete their account setup. This typically involves: * Confirming their email address (often implicitly done by clicking the link). * **Creating a password:** If the workspace allows password-based authentication and the user is not being onboarded directly via OIDC. * **OIDC Onboarding:** If the workspace primarily uses OIDC, the user might be redirected to the Identity Provider (IdP) to authenticate or create an account there if they don't already have one linked. Their Invariant account is then provisioned based on the IdP's authentication. * Agreeing to any terms of service. * Once these steps are completed, their user account in Invariant Technology is created and becomes active. 5. **Post-Activation:** * The user can now log in to the Invariant workspace. * **Initial Permissions:** The user's initial level of access and permissions might be based on default roles or may require further configuration by an administrator after the account is active. It's important to remember that accepting an invitation and creating an account doesn't automatically grant full access to all features. 6. **Expiration/Revocation (Possible States):** * **Expiration:** For security reasons, invitation links may have an expiration period. If not accepted within this timeframe, the link becomes invalid, and a new invitation might need to be sent. * **Revocation:** Administrators may have the ability to revoke a pending invitation before it's accepted if circumstances change. ## Key Considerations for Invitations * **Email Accuracy:** The entire process hinges on the administrator providing the correct email address for the invitee. Typos can lead to undelivered invitations or, worse, invitations sent to the wrong person. * **Email Delivery:** Ensure that emails from Invariant Technology are not being caught by spam filters on the recipient's end. Advise invitees to check their spam/junk folders if they don't receive the invitation promptly. * **User Communication:** It's often helpful for the inviting administrator to give the invitee a heads-up that an invitation email is coming, so they know to expect it. * **Impact of Security Policies:** Workspace security policies, such as "Allow New External Collaborators," directly determine whether invitations can be sent to users outside a managed domain. By understanding these mechanics, both administrators and invited users can navigate the invitation process more effectively, leading to a smoother and more secure onboarding into your Invariant Technology workspace. --- --- --- --- --- --- title: User Rules --- ## Structure Invariant will load and evaluate rules from YAML rules files found in your project directory. Rules can define traffic that should always be deliverable (critical flow rules) or never be deliverable (access policy rules) in your network. Invariant rules files are YAML documents that conform to the specification on this page. ## Overview Invariant supports the following types of rules. | Rule type | Direction | Description | |-----------------------|-----------|-----------------------------------------------------------------------------------------------------------| | ingress-critical-flow | ingress | This traffic should always be successfully delivered. | | egress-critical-flow | egress | | | ingress-deny | ingress | This traffic should never be successfully delivered. | | egress-deny | egress | | | ingress-deny-others | ingress | Within a scope (e.g. TCP traffic), traffic should never be successfully delivered except where permitted. | | egress-deny-others | egress | | Invariant rules are organized into policies which target the same ‘ingress’ or ‘egress’ network. ## Directory Invariant expects rules files to be placed in the directory invariant/policies/ relative to your project directory. ‍ ## Structure ### File structure Invariant rules files must contain a list of policy objects under the top-level key _access-policy_. ‍ ### Policy structure A policy is a named group of related rules which target the same ‘ingress’ or ‘egress’ network. Invariant rules must be placed inside a policy. The following fields can appear in a policy. | Field | Required? | Description | |-----------------|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | name | Yes | An identifier for this policy. Only characters -, _, A-Z, a-z, 0-9 are allowed. | | comment | No | A long description for this policy. | | owner | No | An email address or other identifier for the functional owner of this policy. | | enforce | No | A boolean which can mark the policy unenforced if set to false. Defaults to true. Rules in unenforced policies are still tested but any violations are reported in a separate list. | | ingress-network | Yes (exactly one) | The target network for the rules in this policy. A policy must define ‘ingress-network’ or ‘egress-network’, never both. | | egress-network | | | | rules | Yes | The list of rules in this policy. | ‍ Each policy has an inherent direction - ingress or egress - based on whether ingress-network or egress-network is specified. The rules in the policy must match it. So if the policy has ingress-network specified, only rules of type ‘ingress-critical-flow’, ‘ingress-deny’, and ‘ingress-deny-others’ should appear. ‍ ### Network structure A policy must have an ‘ingress-network’ or ‘egress-network’ and never both. All rules in this policy must match the direction of the policy. A policy with ‘ingress-network’ defined may only contain ‘ingress’ rules. A policy with ‘egress-network’ defined may only contain ‘egress’ rules. Both ‘ingress-network’ and ‘egress-network’ are typically specified as objects, but a shorthand version is available for both. The following fields can appear in ‘ingress-network’. | Field | Required? | Description | |---------------------|----------------------------------------------|---------------------------------------| | destination-address | Yes (at least one) | Defines the ingress network IP space. | | destination-exclude | Subtracts from the ingress network IP space. | | In shorthand mode, ‘ingress-network’ is specified as a CIDR, network name, or list of CIDRs and network names. This is exactly the same as providing destination-address. For example, the following policies are all identical. ‍ ```yaml access-policy: - name: dmz-ingress comment: example owner: example@example.com ingress-network: destination-address: 195.1.1.160/27 195.1.1.192/26 # Shorthand for above access-policy: - name: dmz-ingress comment: example owner: example@example.com ingress-network: 195.1.1.160/27 195.1.1.192/26 # YAML lists are equivalent to space-separated lists access-policy: - name: dmz-ingress comment: example owner: example@example.com ingress-network: - 195.1.1.160/27 - 195.1.1.192/26 ### invariant/policies/dmz.yaml access-policy: - name: dmz-ingress comment: example owner: example@example.com ingress-network: DMZ ### def/networks.yaml networks: DMZ: values: - address: 195.1.1.160/27 - address: 195.1.1.192/26 ``` ‍ The following fields can appear in ‘egress-network’. | Field | Required? | Description | |------------------|--------------------------------------|---------------------------------------------------------------------------------------------| | source-address | Yes (at least one) | Defines the network IP space. | | source-exclude | Subtracts from the network IP space. | | | enter-interface | No | Consider traffic entering on these interfaces. Disables automatic interface selection. | | source-interface | No | Consider traffic originating from these interfaces. Disables automatic interface selection. | Similar to ‘ingress-network’, an ‘egress-network’ with only ‘source-address’ can be specified in shorthand mode. ```yaml access-policy: - name: dmz-egress comment: example owner: example@example.com egress-network: source-address: DMZ # Shorthand access-policy: - name: dmz-egress comment: example owner: example@example.com egress-network: DMZ ``` ### Rule structure Rules define testable statements about traffic that should always be deliverable (critical flow rules) or never be deliverable (access policy rules) in your network. The permitted fields vary by the type of rule. The following fields can appear in any rule. | Field | Required? | Description | |---------|-----------|-------------------------------------------------------------| | type | Yes | The type of this rule. Must be a valid Invariant rule type. | | comment | No | A long description for this rule. | The following fields can appear in rules with type ingress-critical-flow, egress-critical-flow, ingress-deny, egress-deny. | Field | Required? | Description | |---------------------|-----------|--------------------------------------------------------------------------------------------------------------| | protocol | No | The space of possible protocol values for this traffic. | | destination-address | No | The space of possible IP address values for the destination-address field of this traffic. | | destination-exclude | No | Excludes IPs from the space of possible IP address values for the destination-address field of this traffic. | | destination-port | No | The space of possible destination-port values for this traffic. | | source-address | No | The space of possible IP address values for the source-address field of this traffic. | | source-exclude | No | Excludes IPs from the space of possible IP address values for the source-address field of this traffic. | | source-port | No | The space of possible source-port values for this traffic. | | enter-interface | No | Consider traffic entering on these interfaces. Disables automatic interface selection. | | source-interface | No | Consider traffic originating from these interfaces. Disables automatic interface selection. | Deny-others rules assert that no traffic should be deliverable to the target network except as permitted in the rule. These rules can be narrowed down using the ‘within’ section (typically these rules are narrowed by protocol at least). The following fields can appear in rules with type ingress-deny-others, egress-deny-others. | Field | Required? | Description | |-----------------|-----------|-------------------------------------------------------------------------------------------------| | within | No | Narrow the scope of this rule to within this traffic. | | deny-all-except | Yes | Traffic to or from the network should never be deliverable except as permitted in this section. | Inside of a deny-others rule the ‘deny-all-except’ section can contain exactly one field: | Field | Required? | Description | |-------|-----------|------------------------------------------| | flows | Yes | Traffic that is permitted for this rule. | The ‘within’ field and ‘flows’ field both contain a list of traffic flows. Those flows are defined using the same fields as critical-flow and deny rules above. This includes fields like ‘destination-address’, ‘destination-exclude’, ‘source-address’, and so on. ```yaml access-policy: - name: dmz-ingress comment: example owner: example@example.com ingress-network: DMZ rules: - type: ingress-deny-others comment: Limit SSH access to only from bastion network within: - protocol: TCP destination-port: SSH deny-all-except: flows: - comment: Internal SSH access source-address: BASTION destination-port: SSH protocol: TCP ``` ‍ ## Field reference ### Policy fields The following fields can appear in a policy object. #### name Names the current policy. Only characters  -, _, A-Z, a-z, 0-9 are allowed. #### comment Describes the current policy. Some best practices for the comment field: - All policies should use the comment field. - Include ticket references in the comment field if this policy was created or modified in response to a tracking ticket. This allows future users to understand the justification for the policy and confidently make changes to the network. #### owner Identifies the current owner of this policy. Some best practices for the owner field: - The owner should be a primary contact who can comment on proposed changes to this policy. - Value should be an email address or other kind of identifier. #### enforce Mark the policy unenforced if set to false. Defaults to true. Rules in unenforced policies are still tested but any violations are reported in a separate list. #### ingress-network Constrains the destination IP space the rules in this policy will apply to. #### egress-network Defines the source interfaces and source IP space the rules in this policy will apply to. #### rules The list of rules in this policy. ### Rule fields These fields can appear inside rules objects. #### type The type of this rule. Can be one of the following values. - ingress-critical-flow - egress-critical-flow - ingress-deny - egress-deny - ingress-deny-others - egress-deny-others See Rule type reference for more information about each rule type. #### within Allowed only in deny-other rules. This constrains the scope of a deny-other rule using a list of traffic flows. A simple way to think about ‘within’ is to look at a deny-other rule as a boolean expression. ‍ IF traffic matches the network section AND traffic matches the ‘within’ section AND traffic is NOT in the ‘deny-all-except’ list THEN the traffic is in violation of the rule. ‍ Entries listed in the ‘within’ block are ‘OR’-ed together during rule evaluation. #### deny-all-except Allowed only in deny-other rules. This will define the only traffic that should be permitted for the target network (and within the scope of the ‘within’ section if provided). It must contain an object with a single key, ‘flows’, which must contain a list of permitted traffic flows. A simple way to think about deny-other rules is as a boolean expression. ‍ IF traffic matches the network section AND traffic matches the ‘within’ section AND traffic is NOT in the ‘deny-all-except’ list THEN the traffic is in violation of the rule. ‍ ### Traffic flow fields These fields can appear in several places: - Inside a critical-flow or deny rule. - Inside the ‘within’ section of a deny-other rule. - Inside the ‘deny-all-except’ section of a deny-other rule. - Inside the ‘ingress-network’ or ‘egress-network’ section of a policy (only certain fields are permitted in this case - see Network structure above). Taken together these fields define traffic flows or classes of traffic. Invariant thinks about traffic flows as a combination of the following: - Constraints on which interfaces to consider as points of ingress for the traffic. - Constraints on the packet field values. We can categorize all of the fields in this section by whether they represent a constraint on packet field values (e.g. protocol) or a constraint on which interfaces to consider as points of ingress (enter-interface). Source-address / source-exclude and source-interface have the special property that they can create constraints on both. These fields constrain packet field values only: - destination-address - destination-exclude - destination-port - source-port - protocol These fields constrain which interfaces to consider as points of ingress only: - enter-interface These fields can constrain both, depending on the situation: - source-address - source-exclude - source-interface #### destination-address Defines the space of possible IP address values for the destination-address field of this traffic. If destination-exclude is also specified it will be subtracted from this IP space. Acceptable values for destination-address are: - A string listing CIDRs and/or network names separated by a space (or a single CIDR or network name). - A list of CIDRs and/or network names. The following examples show different but equal ways to define destination-address as a list containing a /27 and a /26. ```yaml destination-address: 195.1.1.160/27 195.1.1.192/26 destination-address: - 195.1.1.160/27 - 195.1.1.192/26 ### invariant/policies/dmz.yaml destination-address: DMZ ### def/networks.yaml networks: DMZ: values: - address: 195.1.1.160/27 - address: 195.1.1.192/26 ``` #### destination-exclude Excludes IPs from the space of possible IP address values for the destination-address field of this traffic. If destination-address is not specified, destination-exclude is subtracted from the space of all IP addresses (0.0.0.0-255.255.255.255). Acceptable values for destination-exclude are: - A string listing CIDRs and/or network names separated by a space (or a single CIDR or network name). - A list of CIDRs and/or network names. #### destination-port Defines the space of possible values for the destination-port field of this traffic. Acceptable values for destination-port are: - A string listing service names separated by a space (or a single service name). - A list of service names. The destination-port field must agree with the protocol field. There are two agreement requirements: - All of the IP protocols specified must support the concept of a destination port if destination-port is specified. - All service names must be defined for all of the IP protocols specified. To clarify this last point, it would be an error to create a rule that applies to MYSQL / UDP because the MYSQL service is defined only for TCP. Invariant includes default definitions for many well-known ports. You can override these definitions or add your own custom service names. See well-known ports for a listing of default definitions and their values. ```yaml destination-port: HTTP HTTPS protocol: tcp udp destination-port: - HTTP - HTTPS protocol: tcp udp ### invariant/policies/dmz.yaml destination-port: HTTP protocol: tcp udp ### def/services.yaml services: HTTP: - port: 80 protocol: tcp - port: 80 protocol: udp ``` #### source-port Defines the space of possible values for the source-port field of this traffic. See destination-port above for details. #### protocol Defines the possible IP protocol values for this traffic. The protocol field must agree with the destination-port and source-port fields. There are two agreement requirements: - All of the IP protocols specified must support the concept of a port if destination-port or source-port is specified. - All service names must be defined for all of the IP protocols specified. A list of all acceptable IP protocol names is given on the Batfish documentation site here: [https://batfish.readthedocs.io/en/latest/specifiers.html#ip-protocol-names](https://batfish.readthedocs.io/en/latest/specifiers.html#ip-protocol-names). #### source-address Defines the space of possible source-address IP address values for this traffic. Also defines the interfaces to use as points of ingress for this traffic if source-interface and enter-interface are not specified. This field follows the same conventions as the destination-address field described above. If source-exclude is specified it will be subtracted from this IP space. Acceptable values for source-address are: - A string listing CIDRs and/or network names separated by a space (or a single CIDR or network name). - A list of CIDRs and/or network names. Invariant must decide on interfaces to use as points of ingress for each rule. Source-address is used to identify good points of ingress when source-interface and enter-interface are not specified. The procedure for ingress interface selection is this: - First subtract source-exclude from source-address if specified. - Locate all network interfaces where the assigned IP address falls inside the source address space. - Locate all network interfaces where the primary IP network intersects the source address space. The rule evaluation proceeds with an appropriate subset of the source address space considered for the matched interface. - For an interface where the assigned IP address falls inside the source address space, the question will be evaluated for traffic exiting this interface with source-address restricted to the assigned IP. - For an interface where the primary IP network intersects the source address space, the question will be evaluated for traffic entering this interface with source-address restricted to the intersection of the primary network and original source address space. - An interface can be evaluated twice if it matches both categories. If enter-interface is specified for this traffic, Invariant will look at traffic entering those interfaces. The entire source address space will be considered as possible for all interfaces. No dynamic ingress selection will occur. Source-address and source-exclude are not allowed if source-interface is specified. #### source-exclude Excludes IPs from the space of possible IP address values for the source-address field of this traffic. If source-address is not specified, source-exclude is subtracted from the space of all IP addresses (0.0.0.0-255.255.255.255). Acceptable values for source-exclude are: - A string listing CIDRs and/or network names separated by a space (or a single CIDR or network name). - A list of CIDRs and/or network names. #### enter-interface Consider traffic entering these interfaces. All possible IP address values for source-address will be considered for each interface. Enter-interface is useful for looking at spoofed, reflected, or one-way traffic. For example, if you have a part of your network that is especially untrusted (e.g. guest network, vendor network), you may want to write a rule that says traffic entering from certain interfaces should not be permitted to reach sensitive resources, even if the source of the traffic is a device generating malicious packets with spoofed source IP addresses. Acceptable values are: - A string listing one or more location names separated by spaces. - A list of location names. Location names are names that can resolve to specific interfaces. They are defined by placing a YAML file in the ‘invariant/locations/’ folder. An example location which selects the GigabitEthernet0/1 interface on all edge routers might look like this. ```yaml ### In invariant/locations/edge.yaml locations: EDGE_TO_INTERNET: - devices: border-.* interfaces: GigabitEthernet0/0 ``` The following example shows two cases where enter-interface can be useful. Both cases use a scenario where we want our egress policy for the client VLANs to consider spoofed source addresses. The first policy approaches the problem by asserting that it applies to all traffic entering from the client network - regardless of source address. The second policy approaches the problem by creating a stand-alone policy which asserts that spoofed source IPs are always dropped, so that other policies do not need to worry about spoofed traffic. ```yaml access-policy: - name: client-egress comment: | This policy asserts that traffic entering the CLIENT_BORDER interfaces can reach only necessary resources on the network. It targets the CLIENT_BORDER interfaces directly to ensure the policy applies even to spoofed source addresses. owner: example@example.com egress-network: enter-interface: CLIENT_BORDER rules: - type: egress-deny-others comment: Limit TCP/UDP access to DMZ network, external only within: - protocol: TCP UDP deny-all-except: flows: - comment: Client - DMZ destination-address: DMZ destination-port: HTTP HTTPS SSH - comment: Client - NTP destination-address: NTP destination-port: NTP - comment: Client - DNS destination-address: DNS destination-port: DNS - comment: Client - External destination-exclude: RFC1918 DMZ - name: client-nospoof-egress comment: | This policy targets spoofed traffic entering the CLIENT_BORDER interfaces. It asserts that spoofed traffic is always dropped. With this policy in place we can safely create a normal egress policy that uses source-address: CLIENT_VLANS. owner: example@example.com egress-network: enter-interface: CLIENT_BORDER source-exclude: CLIENT_VLANS rules: - type: ingress-deny comment: Assert all spoofed traffic is dropped destination-address: ANY ### In invariant/locations/client.yaml locations: CLIENT_BORDER: - devices: asa interfaces: GigabitEthernet0/1 GigabitEthernet0/3 ### def/networks.yaml networks: CLIENT_VLANS: values: - address: 192.172.0.0/14 ``` ‍ #### source-interface Consider traffic exiting these interfaces with source IP addresses matching each interface. Source-interface cannot be used in combination with enter-interface or source-address (or source-exclude). Acceptable values are: - A string listing one or more location names separated by spaces. - A list of location names. ## Locations The fields ‘enter-interface’ and ‘source-interface’ expect named locations. This section explains how named locations work and how to create them. ### Overview Named locations are essentially selectors for interfaces in your network. Invariant will search for YAML files containing named location definitions in the ‘invariant/locations’ directory relative to the project root. For example, CLIENT_BORDER here refers to two interfaces on device ‘asa-1’. ```yaml locations: CLIENT_BORDER: - devices: asa interfaces: INSIDE0 INSIDE1 ``` Locations can use wildcards. In this example, EDGE_TO_INTERNET addresses interface GigabitEthernet0/0 on all devices with name matching “border-.*”. ```yaml locations: EDGE_TO_INTERNET: - devices: border-.* interfaces: GigabitEthernet0/0 ``` Locations can be built up from other locations. We can define a new location, UNTRUSTED_INGRESS, to represent all boundary interfaces where high-risk traffic will enter the network. UNTRUSTED_INGRESS will use references to include all interfaces selected by CLIENT_BORDER or EDGE_TO_INTERNET. ```yaml locations: UNTRUSTED_INGRESS: - name: CLIENT_BORDER - name: EDGE_TO_INTERNET EDGE_TO_INTERNET: - devices: border-.* interfaces: GigabitEthernet0/0 CLIENT_BORDER: - devices: asa interfaces: INSIDE0 INSIDE1 ``` It can be helpful to think about these selectors as a boolean expression. For example, UNTRUSTED_INGRESS would be defined as: All interfaces with: - Device name matching “border-.*”some text - AND interface name equal to GigabitEthernet0/0 - OR - Device name equal to “asa”some text - AND interface name equal tosome text - INSIDE0 - OR - INSIDE1 ‍ ### Location file directory Invariant expects named locations to be defined in YAML files located in the directory _invariant/locations/_ relative to your project directory. ### Location file structure Location definition files must contain a mapping from location names to location definitions under the top-level key _locations_. ### Location definition structure A named location is defined using a list of selector objects. The location includes all interfaces matched by any of its selector objects. The following fields can appear in a selector object. | Field | Required? | Description | |------------|-----------|-----------------------------------------------------------------------------------------------------------| | devices | No | The device name must match. Can be an exact match or wildcard. | | interfaces | No | The interface name must match. Can be an exact match or wildcard. | | vrfs | No | The interface VRF name must match. Can be an exact match or wildcard. The default VRF is named “default”. | | zones | No | The interface must belong to a matching zone (for devices with zones). Can be an exact match or wildcard. | | ips | No | The interface primary assigned IP must fall inside this CIDR or named network. | | name | No | Include all interfaces in another named location. | ### Location selector field reference #### devices Selects within devices (nodes) with matching names. In the absence of special characters (asterisk, etc) this will look for exact matches. Wildcards and other regular expression syntax are permitted e.g. ._, [a-z][a-z]_ . #### interfaces Selects within interfaces with matching names. In the absence of special characters (asterisk, etc) this will look for exact matches. Wildcards and other regular expression syntax are permitted e.g. ._, [a-z][a-z]_ . #### vrfs Selects within interfaces with matching VRF name. In the absence of special characters (asterisk, etc) this will look for exact matches. Wildcards and other regular expression syntax are permitted e.g. ._, [a-z][a-z]_ . You may wish to examine the ‘interface_properties’ report in Invariant to get a sense of what VRF name is assigned to what interface. Interfaces are typically assigned to a VRF named ‘default’ when no VRF is explicitly associated. #### zones Selects within interfaces belonging to a zone with matching name. This applies only to devices and nodes that support zones. In the absence of special characters (asterisk, etc) this will look for exact matches. Wildcards and other regular expression syntax are permitted e.g. ._, [a-z][a-z]_ . #### ips Selects within interfaces where the primary assigned IP is inside this CIDR or named network. For example, if we have the primary address of the interfaces pointed towards the internet on our edge routers tagged in our IPAM as “EDGE_TO_INTERNET” we can import that tag as a network name and use it here. We might write a small python script to generate (or re-generate) network names from IPAM tags. ```python # In scripts/regenerate_ipam_networks.py import sys import yaml def regenerate_networks_from_ipam_tags(): ipam_tags = fetch_all_ipam_tags() # ipam_tags is like [{"name": "EDGE_TO_INTERNET", "ips": ["195.24.14.185", "195.24.14.187"]}] ipam_defs = {} for tag in ipam_tags: ipam_defs[tag.name] = { "values": [{"address": ip} for ip in tag.ips] } yaml.safe_dump(ipam_defs, sys.stdout) if __name__ == "__main__": regenerate_networks_from_ipam_tags() ``` Then we can run the script periodically. ```bash python scripts/regenerate_ipam_networks.py > def/generated_ipam_networks.yaml ``` Now we can create a policy which looks at traffic entering from the internet based on that IPAM label. ```yaml ### In invariant/locations/edge.yaml locations: EDGE_TO_INTERNET: - ips: EDGE_TO_INTERNET ### In invariant/policies/edge.yaml access-policy: - name: internet-ingress comment: | This policy asserts that traffic entering the EDGE_TO_INTERNET interfaces can reach only necessary resources on the network. It targets the EDGE_TO_INTERNET interfaces directly to ensure the policy applies even to spoofed source addresses. owner: example@example.com egress-network: enter-interface: EDGE_TO_INTERNET rules: - type: egress-deny-others comment: Limit from-internet TCP/UDP access to specific DMZ services within: - destination-address: DMZ protocol: tcp udp deny-all-except: flows: - comment: Internet - DMZ web servers destination-address: DMZ destination-port: HTTP HTTPS protocol: tcp udp ``` ‍ #### name Include all interfaces that match another named location. A selector containing the name field must be its own list item. ```yaml locations: UNTRUSTED_INGRESS: - name: CLIENT_BORDER - name: EDGE_TO_INTERNET ``` ‍ ## Rule type reference ### ingress-critical-flow Asserts that a traffic flow will always be delivered. Specifically this rule looks for any possible way a packet could be rejected, dropped, or fail to route within this class of traffic. Example: ```yaml access-policy: - name: dmz-ingress comment: | This policy asserts that the DMZ network makes some services available to the internet. owner: example@example.com ingress-network: DMZ rules: - type: ingress-critical-flow comment: Ensure public HTTP/HTTPS access to DMZ resources protocol: TCP UDP destination-port: HTTP HTTPS ``` ‍ ### egress-critical-flow Identical to ingress-critical-flow. Asserts that a traffic flow will always be delivered. Specifically this rule looks for any possible way a packet could be rejected, dropped, or fail to route within this class of traffic. Examples: ```yaml access-policy: - name: basic-internet-access comment: | This policy asserts that some basic internet access (egress) is expected for the target networks. owner: example@example.com egress-network: - DMZ - VLAN30 - CLIENT_VLANS rules: - type: egress-critical-flow comment: Ensure access to 1.1.1.1, 8.8.8.8 etc protocol: TCP UDP destination-address: GOOGLE_DNS CLOUDFLARE_DNS LEVEL3_DNS destination-port: DNS - name: dmz-access-needed comment: | This policy encodes critical dependencies for the DMZ network owner: example@example.com egress-network: DMZ rules: - type: egress-critical-flow comment: Ensure DMZ servers can send telemetry into the protected SEC_LOGS network protocol: TCP UDP destination-address: SEC_LOGS destination-port: HTTPS ``` ‍ ### ingress-deny Asserts that a traffic flow can never be successfully delivered. Specifically this rule looks for any possible way a packet could be successfully delivered within this class of traffic. Example: ```yaml access-policy: - name: ingress-no-ssh comment: | This blanket policy asserts SSH access is denied for any traffic entering from the internet. owner: example@example.com ingress-network: RFC1918 DMZ rules: - type: ingress-deny comment: Ensure public SSH access is denied protocol: TCP UDP enter-interface: EDGE_FROM_INTERNET destination-port: SSH ``` ‍ ### egress-deny Identical to ingress-deny. Asserts that a traffic flow can never be successfully delivered. Specifically this rule looks for any possible way a packet could be successfully delivered within this class of traffic. Example: ```yaml access-policy: - name: egress-malicious-nets comment: | This blanket policy asserts outbound access is denied to certain malicious networks. owner: example@example.com egress-network: RFC1918 rules: - type: egress-deny comment: Ensure outbound access to malicious networks is not allowed protocol: TCP UDP destination-address: MALICIOUS_PUBLIC_IPS ``` ‍ ### ingress-deny-others ‍ Asserts that traffic can never be successfully delivered to the target network except for specific permitted flows. This rule looks for any possible way a forbidden packet could be successfully delivered. The optional ‘within’ field restricts the scope of the rule. Although the field is optional, almost all deny-others rules will need to be restricted by protocol. There are two reasons for this: - Not all IP protocols support the concept of ports. Rules that use destination-port or source-port need to use ‘within’ to restrict the rule scope to IP protocols that support ports (e.g. TCP, UDP). - Many users are focused on TCP, UDP access policy and are not prepared to establish policy for other IP protocols. When reasoning about deny-others rules it can be helpful to treat the rule as a boolean expression: ‍ IF traffic matches the network section AND traffic matches the ‘within’ section AND traffic is NOT in the ‘deny-all-except’ list THEN the traffic is in violation of the rule. ‍ Example: ```yaml access-policy: - name: dmz-ingress comment: example owner: example@example.com ingress-network: DMZ rules: - type: ingress-deny-others comment: Limit SSH access to only from bastion network within: - source-address: RFC1918 protocol: tcp deny-all-except: flows: - comment: Internal SSH access source-address: BASTION destination-port: SSH protocol: tcp ``` ‍ ### egress-deny-others Identical to ingress-deny-others. Asserts that traffic can never be successfully delivered to the target network except for specific permitted flows. This rule looks for any possible way a forbidden packet could be successfully delivered. See ingress-deny-others for more information. Example: ```yaml access-policy: - name: client-egress comment: | This policy asserts that traffic entering the CLIENT_BORDER interfaces can reach only necessary resources on the network. It targets the CLIENT_BORDER interfaces directly to ensure the policy applies even to spoofed source addresses. owner: example@example.com egress-network: enter-interface: CLIENT_BORDER rules: - type: ingress-deny-others comment: Limit TCP/UDP access to DMZ network, external only within: - protocol: TCP UDP deny-all-except: flows: - comment: Client - DMZ destination-address: DMZ destination-port: HTTP HTTPS SSH - comment: Client - NTP destination-address: NTP destination-port: NTP - comment: Client - DNS destination-address: DNS destination-port: DNS - comment: Client - External destination-exclude: RFC1918 DMZ ``` --- * Mention what Invariant is again ![Invariant Overview Diagram](img/invariant_process.svg) asdasd * Describe step 1 * Describe step 2 * Describe step 3 * Describe step 4 * Describe step 5 * Describe step 6 * Describe step 7 --- ## Networks in Invariant? An Invariant Network is a time-series of snapshots of your network. You can think of them as a folder where the you can upload your snapshots for processing. An Invariant Network is a time-series of snapshots of your network allowing you to * Validate your network against your security policy. * Ensure network changes will not break critical services. * Chart your networks health over time. * Monitor your network for breakages. When Networks in Invariant are constructs used to organize your uploads, reports, policies and more. You can think of them as a folder that holds together the historical information about a network. By default, every upload to Invariant is linked to a default Network. When uploading a snapshot a digital twin is built, analyzed according to your policies, and the results are stored under this default Network. In this way you can consider them like a folder. Snapshots of your network are stored and can be looked at historically to see how the network has changed over time. A lot of features are based around Networks such as notifications and integrations. ## When to use an Invariant Network? You can use networks to help break down your company's network into smaller components. For example you might have separate teams that manage the data center, enterprise and cloud environments. Those teams would like to only be notified when their own network has a violation. Breaking the networks down by those teams would be a straightforward way to achieve this goal. You may also have intended configurations you work on prior to deployment versus live configurations pulled from the devices regularly. You may wish to create separate networks for these to be able to track impending violations due to change versus violations introduced to the live network. # Snapshots # Monitoring # -- Invariant networks contain a series of snapshots, provides access to those snapshots Network,mupload snapshots to snapshots two kinds of snapshots, network snapshots versus Invariant snapshots More specific descirptions of Invariant's capabilities monitoring network health chart list of snapshots --- ## What is a flow? In Invariant we talk about flows between subnets a lot. A flow draws a path through your network between subnets. asdasd * 5 Tuples * Draws a path through the network * Each path is a flow ```mermaid graph TD; '172.10.0.1/32'-->B; A-->C; B-->D; C-->D; ``` ## Multipath * Flows can go through multiple paths * Each one is an individual flow * How a packet is treated is highly dependent on flows ## Locations * Locations give you more control over where packets start * EXTERNAL is a special location --- * Rules define the 5 tuples to be checked * Unlike an ACL we are looking at behavior across the network ### Commonalities across rules * All rules talk about flows * All rules can have owners and comments * Rule types are prefixed with either ingress or egress and must match their policy type ### Critical Flows * CF's ensure that one subnet can connect to another * They are more robust than a traceroute because they exhaustively search * Considers routing and firewalling * Diagram showing a critical flow * Use this to ensure services are still accessible after network changes ### Deny * Deny determines if there is any way the flow can get into or out of the subnet. * Multipath aware. * Exhaustive search through the network. * Useful for expressing behavior you never want to see ### Deny Except * Deny Except is best thought of via a venn diagram * Select all traffic you want to consider then subtract what is allowed * Useful for expressing exhaustive inbound and outbound flows for highly sensitive networks ## Access Policy * Access Policy contains the policy for a subnet * Multiple Policies can be made for the subnet * Policies and their rules can overlap, they run independantly * Comments and owners in access policy are useful for organization ### Ingress/Egress * When defining a policy it must be an ingress or egress type * All rules must be of the same policy type * It locks one side of IPs in the 5 tuple --- --- title: REST API Introduction slug: /reference/api/introduction sidebar_label: Introduction --- # REST API Invariant offers several options for programmatic access and automation. All of the methods below allow you to control Invariant in an automated fashion, but we generally recommend using the CLI or the PySDK for most automation tasks: * **Invariant CLI:** **(Recommended for Automation)** * The CLI is the preferred tool for integrating Invariant into CI/CD pipelines, scripts, and other automation workflows. * **Benefits:** Handles authentication, access token refresh, and service back-off/retry logic automatically. Provides structured JSON output (and TSV for tabular data), making it easy to parse output across all supported interactions. Language-agnostic. * **Invariant PySDK:** * Included within the `invariant-client` Python package, the PySDK offers a Pythonic interface for interacting with Invariant. * **Benefits:** Provides a more integrated experience for Python developers. Like the CLI, it simplifies authentication. Aims for complete coverage of the REST API surface. Provides data models and type hints for all interfaces. * **Invariant REST API:** * Direct interaction with the REST API is possible but somewhat more complex to implement correctly. Follow the instructions below. The OpenAPI schema is available. **Recommendation:** If you can achieve your goals using the CLI or the PySDK, we recommend starting there before considering direct REST API integration. ### Overview Direct API interaction requires you to manually handle: 1. Obtaining short-lived **Access Tokens** using your long-lived **API Token**. 2. Including the Access Token in the `Authorization` header for your API requests. 3. Refreshing the Access Token when it expires. ### Prerequisites Before you start, ensure you have: 1. **An API Token:** Generate this from the Invariant Web UI under `Settings -> API Tokens`. **Treat this token like a password; keep it secure.** This token functions as a *Refresh Token* in the authentication flow. 2. **Your Organization Name:** This is the unique identifier for your organization within Invariant (visible in the URL when logged into the web UI, e.g., `app.prod.invariant.tech/YOUR_ORG_NAME/`). ## Authentication Flow The process involves using your long-lived API Token (acting as a refresh token) to get a short-lived Access Token, which you then use for subsequent API calls. ### Step 1: Obtain an Access Token To get an Access Token, you need to make a `POST` request to the `/refresh` endpoint on your **Instance API Base URL**. You must send your API Token as a cookie named `refresh_token_cookie`. **Endpoint:** `POST /{organization_name}/api/v1/refresh` **Headers:** None required initially. **Cookies:** * `refresh_token_cookie`: Your long-lived API Token obtained from the UI. **Example (`curl`):** ```bash # Replace ORGANIZATION_NAME and YOUR_API_TOKEN with your actual values. # Fetch or inject YOUR_API_TOKEN from an appropriate secret storage. ORGANIZATION_NAME="ORGANIZATION_NAME" INVARIANT_API_TOKEN="YOUR_API_TOKEN" INVARIANT_BASE_URI="https://app.prod.invariant.tech" curl -X POST \ "${INVARIANT_BASE_URI}/${ORGANIZATION_NAME}/api/v1/refresh" \ -H "Content-Type: application/json" \ -b "refresh_token_cookie=${INVARIANT_API_TOKEN}" \ -d '{}' # Body is required but can be empty ``` **Successful Response (200 OK):** The response will be a JSON object containing the short-lived Access Token: ```json { "status": 200, "type": "urn:invariant:responses:refresh_response", "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." } ``` * **Extract the `access_token` value.** This token is valid for 10 minutes. **Error Responses:** * **401 Unauthorized / 403 Forbidden:** Your API Token (refresh token) might be invalid, revoked, expired, or the cookie might be missing/incorrectly named. * **404 Not Found:** Your organization name might be incorrect in the URL. ### Step 2: Make Authenticated API Calls Use the obtained Access Token to make calls to other endpoints on the **Instance API Base URL**. Include the token in the `Authorization` header using the `Bearer` scheme. **Example (`curl` - Listing Reports):** ```bash # Replace ORGANIZATION_NAME and ACCESS_TOKEN with your actual values ORGANIZATION_NAME="ORGANIZATION_NAME" ACCESS_TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..." # From Step 1 INVARIANT_BASE_URI="https://app.prod.invariant.tech" curl -X GET \ "${INVARIANT_BASE_URI}/${ORGANIZATION_NAME}/api/v1/reports/" \ -H "Authorization: Bearer ${ACCESS_TOKEN}" ``` ### Step 3: Handling Token Expiry Access Tokens expire quickly. If an API call returns a 401 Unauthorized error, your Access Token has likely expired. * **Repeat Step 1:** Use your original long-lived API Token (as the `refresh_token_cookie`) to call the `/refresh` endpoint again and obtain a *new* Access Token. * **Retry Request:** Use the new Access Token to retry the failed API call. Your long-lived API Token does not expire unless manually revoked. ## Security Considerations * **Protect your API Token:** Store it securely, just like a password. Do not commit it to version control. ## OpenAPI Schema For detailed information on available endpoints, request/response schemas, and parameters, please refer to the OpenAPI specifications: * **Login/Auth API:** [schema/openapi_login.json](https://github.com/InvariantTech/client/blob/main/schema/openapi_login.json) - Covers endpoints primarily used by the web UI login flow, but useful for understanding authentication mechanisms. * **Instance API:** [schema/openapi.json](https://github.com/InvariantTech/client/blob/main/schema/openapi.json) - Covers the main operational endpoints available after authentication (e.g., uploading snapshots, listing reports). You can use tools like Swagger UI or Postman to explore these specifications interactively. --- --- title: Install the Invariant CLI using pip --- Install the Invariant CLI using pip, the Python package installer. ```bash pip install invariant-client ``` Verify the installation by checking the version. ```bash invariant --version # client: vX.Y.Z # server: vA.B.C ``` --- See the [Quick Start guide](/Get-Started/Quick-Start) for next steps, like logging in. --- --- title: Install the Invariant CLI from source --- Install the Invariant CLI directly from the source code repository using git and Poetry. ```bash git clone https://github.com/InvariantTech/client cd client poetry install ``` Verify the installation by checking the version. ```bash poetry run invariant --version # client: vX.Y.Z # server: vA.B.C ``` --- See the [Quick Start guide](/Get-Started/Quick-Start) for next steps, like logging in. --- --- title: Log in using the CLI --- Use the `invariant login` command to authenticate the Invariant CLI with your Invariant account. Run the command in your terminal: ```bash $ invariant login ``` This command prints a unique URL to your terminal. ```text Open this link in your browser to log in: https://prod.invariant.tech/login?code=123456 ``` Open this URL in your web browser and complete the sign-in process via the web interface. After successful authentication in the browser, the CLI will display a confirmation message. ```text Logged in as your-email@example.com (tenant=your-organization-name). ``` Confirm that the `tenant` field matches your organization. Your CLI session is now authenticated and can interact with the Invariant API. Authentication tokens are stored locally and will expire after a period of inactivity or 24 hours. Never share the login code with anyone. --- --- title: Add a Network to Invariant --- Invariant Networks organize snapshots for different environments or network segments. --- To add a new Network using the Invariant UI: 1. Navigate to `Settings` in the top navigation bar. 2. Scroll down to the **Networks** section. 3. Click **Add Network**. 4. Provide a unique **Network Name** and an optional **Description**. 5. Click **Create Network**. Enter a unique name for your network and submit the form. --- Networks can be referenced when uploading snapshots via the CLI. ```bash $ invariant run --network ``` If the `--network` option is not provided, Invariant will upload to the network named 'default', which acts as a catch-all. You can remove the network 'default' to cause the `--network` to be required. --- --- title: Package and upload a network snapshot --- Create the following directory structure to represent a network snapshot. ```bash my-network-snapshot/ ├── aws_configs/ # AWS JSON configuration files ├── batfish/ # Batfish ISP configuration (isp_config.json) ├── configs/ # On-premise device configurations ├── def/ # Network and service definitions (Aerleon or Capirca) └── invariant/ ├── locations/ # Location definitions (YAML) └── policies/ # Access policy rules (YAML) ``` --- - `configs/`: Contains on-premise device configurations (Cisco, Juniper, Arista, etc.). - `aws_configs/`: Contains AWS resource configurations (optional, requires specific structure for accounts/regions if used). - `batfish/`: Holds optional Batfish configuration like `isp_config.json`. - `def/`: Contains YAML files defining named networks (IP ranges) and services (ports/protocols) defined in Aerleon format. Capirca format is also accepted. - `invariant/locations/`: Contains YAML files defining named locations (mapping names to device interfaces). - `invariant/policies/`: Contains YAML files defining access policy and critical flow rules. --- Run `invariant run` using the `my-network-snapshot` directory to upload the snapshot and start the analysis and evaluation process. If you have not already, [create a Network to represent the target network](add-a-network-to-invariant) ```bash # Upload the current directory as a snapshot $ cd my-network-snapshot $ invariant run --network my-network # Specify the snapshot directory using --target $ invariant run --network my-network --target my-network-snapshot ``` --- See [Docs > Reference > Snapshots](/Reference/Snapshots) for detailed directory structure and file format information. --- --- title: Configure a placeholder ISP --- To test egress policies or default routes accurately, you may need to model external connectivity like the Internet or a private backbone. Create a JSON file at `batfish/isp_config.json` within your snapshot directory. --- Define the interfaces on your border routers that connect to the external network and define the placeholder ISP(s). ```json title="batfish/isp_config.json" { "borderInterfaces": [ { "borderInterface": { "hostname": "your-border-router-hostname-1", "interface": "GigabitEthernet0/1" } }, { "borderInterface": { "hostname": "your-border-router-hostname-2", "interface": "GigabitEthernet0/3" } } ], "ispNodeInfo": [ { "asn": 64501, "name": "ISP1_Transit", "role": "TRANSIT" // Models Internet, provides default route }, { "asn": 64502, "name": "ISP2_Backbone", "role": "PRIVATE_BACKBONE" // Models private peering, no default route } ] } ``` - `borderInterfaces`: List the interfaces on your devices connecting externally. - `ispNodeInfo`: Define each placeholder ISP with its ASN, name, and role. - `TRANSIT`: Simulates a standard Internet Service Provider, injecting a default route. - `PRIVATE_BACKBONE`: Simulates a private connection (like MPLS), does not provide a default route. Upload the snapshot using `invariant run` to re-evaluate the network with external network model in place. --- See [Docs > Reference > Snapshots](/Reference/Snapshots#batfish) for more details on isp_config.json structure. --- --- title: Use IP network and service names from Aerleon --- Invariant natively supports network and service definition files in the Aerleon format. --- Place your definition files in the `def/` directory of your snapshot. ```bash snapshot/ └── def/ ├── networks.yaml └── services.yaml ``` --- ## Example Network Definitions ```yaml title="invariant/def/networks.yaml" networks: DB_SERVERS: values: - address: 10.50.1.10/32 - address: 10.50.1.11/32 RFC1918: values: - name: RFC1918_10_SPACE # Include other network - name: RFC1918_172_SPACE - name: RFC1918_192_SPACE RFC1918_10_SPACE: values: - address: 10.0.0.0/8 RFC1918_172_SPACE: values: - address: 172.16.0.0/12 RFC1918_192_SPACE: values: - address: 192.168.0.0/16 ``` --- ## Example Service Definitions ```yaml title="invariant/def/services.yaml" services: HIGH_PORTS: values: - port: 1024-65535 protocol: tcp udp SSH: values: - port: 22 protocol: tcp ``` Services can include other services. ```yaml title="invariant/def/services.yaml" services: NMSP: - name: NMSP_537 - name: NMSP_1790 NMSP_1790: - port: 1790 protocol: tcp - port: 1790 protocol: udp NMSP_537: - port: 537 protocol: tcp - port: 537 protocol: udp ``` --- Reference these named definitions directly in your Invariant access policy rules. ```yaml title="invariant/policies/my_policy.yaml" access-policy: - name: db-access ingress-network: DB_SERVERS # Use named network rules: - type: ingress-deny source-address: RFC1918 # Use named network destination-port: SSH # Use named service ``` --- Built-in definitions for common IP networks (like RFC1918) and IANA well-known services are automatically loaded by Invariant. See [Reference well-known networks and services in Invariant](3-reference-wellknown-networks-and-services-in-invariant.md) See [Access Policy](/Reference/Access_Policy) for more details on writing rules. --- --- title: Use IP network and service names from Capirca --- Invariant natively supports network and service definition files in the Capirca format. :::caution Important We recommend migrating from Capirca .def format to Aerleon YAML format if possible for several reasons: * The Capirca .def format is not formally specified or documented. * Tooling to programmatically work with Capirca .def format is very sparse. ::: Aerleon and Capirca files define networks and services into the same namespace. See also: [Use IP network and service names from Aerleon](1-use-ip-network-and-service-names-from-aerleon.md) --- Place your definition files in the `def/` directory of your snapshot. ```bash snapshot/ └── def/ ├── networks.net └── services.svc ``` --- Example `networks.net`: ```txt title="invariant/def/networks.net" DB_SERVERS = 10.50.1.10/32, 10.50.1.11/32 RFC1918 = RFC1918_10_SPACE, RFC1918_172_SPACE, RFC1918_192_SPACE RFC1918_10_SPACE = 10.0.0.0/8 RFC1918_172_SPACE = 172.16.0.0/12 RFC1918_192_SPACE = 192.168.0.0/16 ``` --- Example `services.svc`: ```txt title="invariant/def/services.svc" HIGH_PORTS = 1024-65535/tcp, 1024-65535/udp SSH = 22/tcp ``` Services can include other services. ```txt title="invariant/def/services.svc" NMSP = NMSP_537, NMSP_1790 NMSP_537 = 537/tcp, 537/udp NMSP_1790 = 1790/tcp, 1790/udp ``` --- Reference these named definitions directly in your Invariant access policy rules. ```yaml title="invariant/policies/my_policy.yaml" access-policy: - name: db-access ingress-network: DB_SERVERS # Use named network rules: - type: ingress-deny source-address: RFC1918 # Use named network destination-port: SSH # Use named service ``` --- Built-in definitions for common IP networks (like RFC1918) and IANA well-known services are automatically loaded by Invariant. See [Reference well-known networks and services in Invariant](3-reference-wellknown-networks-and-services-in-invariant.md) See [Access Policy](/Reference/Access_Policy) for more details on writing rules. --- --- title: Reference well-known networks and services in Invariant --- Invariant includes built-in definitions for common IP networks (like RFC1918) and IANA well-known services (like HTTP, SSH) for convenience. A reference list of built-in names and sources is available here: [https://github.com/InvariantTech/built-ins](https://github.com/InvariantTech/built-ins) --- Use the built-in names directly in your policy files (e.g., `invariant/policies/my_policy.yaml`) or definition files (`def/networks.yaml`, `def/services.yaml`): ```yaml access-policy: - name: deny-ssh-from-internet-to-private comment: Deny SSH from the internet to private IP space ingress-network: RFC1918 # Built-in network name rules: - type: ingress-deny comment: Block external SSH attempts destination-port: SSH # Built-in service name protocol: tcp ``` --- ## Override User-defined networks or services with the same name in your `def/` directory will override the built-in definitions. ```yaml networks: RFC1918: # You may quietly override built-in values - 10.0.0.0/8 - 172.16.0.0/12 - 192.168.0.0/16 ``` --- See [Docs > Access Policy](/AccessPolicy) for more details on writing rules. --- --- title: List network snapshots using the CLI --- Use the `invariant snapshots` command to list prior snapshot analysis results for your networks. ```bash # List snapshots for the default network $ invariant snapshots ``` The output displays a table with snapshot details including UUID and creation time. ```bash # Example Output +--------------------------------------+---------+---------------------+---------+----------------+ | uuid | network | created_at | status | ap_violations |... |--------------------------------------+---------+---------------------+---------+----------------| | adf11172-9f8a-4333-b7c7-f9f0ecefe8d9 | default | 2024-01-01T12:00:00 | success | 0 |... | 6c334806-126c-4b63-bafe-495b39fdf995 | default | 2024-01-02T14:30:00 | success | 1 |... +--------------------------------------+---------+---------------------+---------+----------------+... ``` Use `--network` to filter by network name. Use `--tsv` or `--json` for control the output format. ```bash # List snapshots for a specific network in TSV format $ invariant snapshots --network live_scans --tsv # List snapshots for a specific network in JSON format $ invariant snapshots --network live_scans --json # List snapshots for a specific network in JSON format (no whitespace) $ invariant snapshots --network live_scans --fast-json ``` --- See [Reference > CLI](/Reference/CLI) for complete CLI documentation. --- --- title: List network snapshots using the UI --- To view network snapshots within the Invariant web interface: 1. **Log in** to your Invariant account at `https://prod.invariant.tech/login`. 3. Select the specific **Network** you want to inspect from the network selector. 4. Click on the network history graph on the main view for the selected network to display a list of its **Snapshots**, showing the snapshot ID (UUID), creation date/time, and status. --- --- title: Detect simulated route table changes using Invariant --- To detect changes in simulated route tables between two network snapshots, fetch the `routes` report for each snapshot and compare them. First, retrieve the `routes` report for your current snapshot and save it as JSON. Replace `` with the actual snapshot ID. ```bash invariant show routes --snapshot --json > current_routes.json ``` --- Next, retrieve the `routes` report for the previous or baseline snapshot you want to compare against. Replace `` with its ID. ```bash invariant show routes --snapshot --json > previous_routes.json ``` --- Finally, use a diff tool to compare the two JSON files. Differences indicate changes in the route tables between the snapshots. ```bash diff current_routes.json previous_routes.json # Example output might show added (+) or removed (-) routes: # < "Network": "10.20.0.0/16", # < "Next_Hop_IP": "169.254.25.161", # --- # > "Network": "10.20.0.0/16", # > "Next_Hop_IP": "0.0.0.0", # Example change indicating route loss ``` --- See [Output > Network Information > routes](/Reference/Output/NetworkInformation/routes) for report details. --- --- title: Detect simulated BGP changes using Invariant --- To detect changes in simulated BGP sessions between two network snapshots, fetch the `bgp_session_status` report for each snapshot and compare them. First, retrieve the report for your current snapshot. Replace `` with the actual snapshot ID. ```bash invariant show bgp_session_status --snapshot --json > current_bgp_sessions.json ``` --- Next, retrieve the report for the previous or baseline snapshot. Replace `` with its ID. ```bash invariant show bgp_session_status --snapshot --json > previous_bgp_sessions.json ``` --- Use a diff tool to compare the two files. Changes in the `Established_Status` field indicate differences in BGP session establishment. ```bash diff current_bgp_sessions.json previous_bgp_sessions.json # Example output might show a change in session status: # < "Local_IP": "169.254.25.161", # < "Established_Status": "ESTABLISHED", # --- # > "Local_IP": "169.254.25.161", # > "Established_Status": "NOT_ESTABLISHED", # Example change ``` --- See [Output > BGP > bgp_session_status](/Reference/Output/BGP/bgp_session_status) for report details. --- --- title: Detect simulated IPSec tunnel changes using Invariant --- To detect changes in simulated IPSec tunnels between two network snapshots, fetch the `ipsec_edges` report for each snapshot and compare them. First, retrieve the report for your current snapshot. Replace `` with the actual snapshot ID. ```bash invariant show ipsec_edges --snapshot --json > current_ipsec_edges.json ``` --- Next, retrieve the report for the previous or baseline snapshot. Replace `` with its ID. ```bash invariant show ipsec_edges --snapshot --json > previous_ipsec_edges.json ``` --- Use a diff tool to compare the two files. Differences will highlight added or removed IPSec edges, indicating changes in tunnel establishment. ```bash diff current_ipsec_edges.json previous_ipsec_edges.json # Example output might show removed (-) edges: # < "Tunnel_Interface_str": "border-1[Tunnel1]", # < "Source_Interface_str": "tgw-06b348adabd13452d[external-vpn-01c45673532d3e33e-1]" # --- # > (This edge might be missing in the current file) ``` --- Refer to Invariant output documentation for `ipsec_edges` details (Note: This specific report wasn't listed in the provided `Output` overview but is demonstrated in the Jenkins automation example). --- --- title: Detect simulated OSPF changes using Invariant --- To detect changes in simulated OSPF sessions between two network snapshots, fetch the `ospf_session_compatibility` report for each snapshot and compare them. First, retrieve the report for your current snapshot. Replace `` with the actual snapshot ID. ```bash invariant show ospf_session_compatibility --snapshot --json > current_ospf_sessions.json ``` --- Next, retrieve the report for the previous or baseline snapshot. Replace `` with its ID. ```bash invariant show ospf_session_compatibility --snapshot --json > previous_ospf_sessions.json ``` --- Use a diff tool to compare the two files. Changes in the `Session_Status` field indicate differences in OSPF session establishment between the snapshots. ```bash diff current_ospf_sessions.json previous_ospf_sessions.json # Example output might show a change in session status: # < "Interface": "core-1[GigabitEthernet0/0]", # < "Session_Status": "OSPF_SESSION_ESTABLISHED", # --- # > "Interface": "core-1[GigabitEthernet0/0]", # > "Session_Status": "NO_SESSION", # Example change ``` --- See [Output > OSPF > ospf_session_compatibility](/Reference/Output/OSPF/ospf_session_compatibility) for report details. --- --- title: Detect simulated VLAN changes using Invariant --- To detect changes in VLAN configurations between two network snapshots, fetch the `vlan_properties` report for each snapshot and compare them. First, retrieve the report for your current snapshot. Replace `` with the actual snapshot ID. ```bash invariant show vlan_properties --snapshot --json > current_vlan_properties.json ``` --- Next, retrieve the report for the previous or baseline snapshot. Replace `` with its ID. ```bash invariant show vlan_properties --snapshot --json > previous_vlan_properties.json ``` --- Use a diff tool to compare the two files. Differences will show changes in VLAN IDs, associated interfaces, or VXLAN VNIs. ```bash diff current_vlan_properties.json previous_vlan_properties.json # Example output might show an interface removed (-) from a VLAN: # < "Interfaces": [ # < "dist-1[Ethernet1]", # < "dist-1[Ethernet2]" # < ], # --- # > "Interfaces": [ # > "dist-1[Ethernet1]" # > ], ``` --- See [Output > Network Information > vlan_properties](/Reference/Output/NetworkInformation/vlan_properties) for report details. --- --- title: Access pass-fail validation outcome for a network snapshot --- To quickly determine if a network snapshot passed all configured rules after analysis, use the `invariant run` command with the `--condensed` flag. ```bash $ invariant run --condensed snapshot: cf2bb04f-554f-4a84-a3e0-bf12a13c0e4e outcome: All rules passed ``` To determine the status of an existing network snapshot, use `invariant show` with the snapshot ID. ```bash $ invariant show --snapshot cf2bb04f-554f-4a84-a3e0-bf12a13c0e4e --condensed snapshot: cf2bb04f-554f-4a84-a3e0-bf12a13c0e4e outcome: All rules passed ``` Check the `outcome:` line in the output: - `outcome: All rules passed` indicates the snapshot passed all checks. - `outcome: Rule violations found` indicates one or more rules failed or were violated. --- See [Output Overview](/Reference/Output/Output) for more details on analyzing results. --- --- title: Access pass-fail validation outcome for a specific rule --- To check the pass/fail status of a specific access policy or critical flow rule after running `invariant run`, examine the relevant `_ok` or `_violations` report files using `invariant show --json`. Use a tool like `jq` to filter the JSON output and check the `ok` field for your rule. ```bash # Check if a *specific* access policy rule within 'datacenter-security-policy' passed # Looks for the rule based on its comment containing "VLAN30" $ invariant show policy_ok --json | jq '.[] | select(.policy.name == "datacenter-security-policy" and (.rule.comment // "") | contains("VLAN30")) | .ok' true ``` ```bash # Check if a *specific* access policy rule within 'datacenter-security-policy' violated # Looks for the rule based on its comment containing "VLAN40" $ invariant show policy_violations --json | jq '.[] | select(.policy.name == "datacenter-security-policy" and (.rule.comment // "") | contains("VLAN40")) | .ok' false ``` - Check the `policy_ok` or `critical_flows_ok` reports. If your rule is present and `ok` is `true`, it passed. - Check the `policy_violations` or `critical_flows_violations` reports. If your rule is present and `ok` is `false`, it failed. - If the rule is not found in either the `_ok` or `_violations` report for its type, it may have been skipped due to errors (check `policy_skipped` or `critical_flows_skipped`). --- See [Access Policy Output Files](/Reference/Output/Output) for more details on report files. --- --- title: Validate ACL behavior using Invariant description: Use Invariant Access Policy rules to verify network access control list (ACL) behavior. --- ACLs sometimes don't behave as expected. Common issues include partially or fully shadowed lines, typos, and subtle misunderstandings of ACL commands. Use Invariant to confirm that ACL behavior matches your expectations. --- **Scenario:** The firewall `asa.cfg` has access list `internal-to-external` applied inbound on its interfaces facing internal networks. It should permit SSH from VLAN10 (`192.168.10.0/24`) and deny SSH from all other VLANS. ```acl title="configs/asa.cfg" interface GigabitEthernet0/1 nameif INSIDE1 ... access-list internal-to-external remark allow-ssh-from-eng access-list internal-to-external extended permit tcp 192.168.10.0 255.255.255.0 any eq ssh access-list internal-to-external remark deny-internal access-list internal-to-external extended deny tcp any 10.0.0.0 255.0.0.0 access-list internal-to-external extended deny udp any 10.0.0.0 255.0.0.0 ! ... other deny rules ... access-group internal-to-external in interface INSIDE1 ``` --- **Verification:** Let's verify that ACL `internal-to-external` actually has these behaviors: * Permits SSH from VLAN10 (`192.168.10.0/24`) * Denies SSH from all other VLANs (`192.168.0.0/16`) ```yaml title="invariant/policies/asa_validation.yaml" access-policy: - name: asa-ssh-validation-VLAN10 comment: Confirm VLAN10 SSH access owner: security-team@example.com egress-network: VLAN10 rules: - type: egress-critical-flow comment: Ensure VLAN10 can SSH into the datacenter via ASA destination-address: DATACENTER destination-port: SSH # Built-in service name protocol: tcp - name: asa-ssh-validation-VLANS comment: Validate ACLs protecting the datacenter owner: security-team@example.com egress-network: source-address: VLANS source-exclude: VLAN10 # Select all VLANS excluding VLAN10 rules: - type: egress-deny comment: Ensure other VLANS cannot SSH anywhere destination-port: SSH # Built-in service name protocol: tcp ``` **Run Analysis:** Execute Invariant on your snapshot directory. ```bash $ invariant run --target /path/to/your/snapshot/ --condensed snapshot: cf2bb04f-554f-4a84-a3e0-bf12a13c0e4e outcome: All rules passed # Passing rules are listed in policy_ok $ invariant show policy_ok --json # A log of reachability checks performed appears in policy_logs $ invariant show policy_logs --json # Violations, if present, would appear in policy_violations $ invariant show policy_violations --json # Traceroutes demonstrating segmentation violations, if found, appear in policy_details $ invariant show policy_details --json ``` Similarly, details for the critical flow rule can be found in critical_flows_ok , etc. --- See [Access Policy](/AccessPolicy) for more details on rule types and reports. See [Output Overview](/Reference/Output/Output#access-policy-files) for access policy output file reference. --- --- title: Validate VLAN segmentation using Invariant description: Use Invariant Access Policy rules to ensure proper network segmentation between VLANs. --- Use Invariant Access Policy rules (`ingress-deny-others` or `egress-deny-others`) to define and enforce strict network segmentation between VLANs. --- **Scenario:** Ensure the sensitive VLAN40 (`192.168.40.0/24`) only allows inbound TCP connections via SSH, and only from a specific host `ALICE_DESKTOP` (`192.168.10.98/32`), denying all other internal TCP traffic. **Example ACLs:** Segmentation is enforced by ACLs on the `dist-1` and `dist-2` switch virtual interfaces (SVIs) for VLAN40. `vlan40-in` denies traffic sourced from other internal networks, while `vlan40-out` (applied egress, but relevant to the inbound flow decision on some platforms) explicitly permits SSH *from* ALICE_DESKTOP. ```acl title="configs/dist-1.cfg (and dist-2.cfg)" ip access-list vlan40-in remark deny-internal deny ip any 10.0.0.0/8 deny ip any 172.16.0.0/12 deny ip any 192.168.0.0/16 remark accept-internet permit ip any any ip access-list vlan40-out remark allow-ssh permit tcp host 192.168.10.98 any eq ssh ! Allow SSH from ALICE_DESKTOP remark deny-internal deny ip any 10.0.0.0/8 deny ip any 172.16.0.0/12 deny ip any 192.168.0.0/16 ! Deny other cross-VLAN access interface Vlan40 ip address 192.168.40.253/24 ! (or .252 on dist-2) ip access-group vlan40-in in ip access-group vlan40-out out ``` --- **Invariant Policy:** Define an `ingress-deny-others` rule in `invariant/policies/segmentation.yaml` to verify this specific segmentation. ```yaml title="invariant/policies/segmentation.yaml" access-policy: - name: sensitive-vlan40-segmentation comment: Enforce strict segmentation for VLAN40 owner: security-team@example.com ingress-network: destination-address: VLAN40 destination-exclude: VLAN40_IF # Exclude router interface IPs, they are in front of the ACL rules: - type: ingress-deny-others comment: Limit TCP ingress to only SSH from Alice's desktop within: # Scope the denial: deny all cross-VLAN ingress except as permitted - protocol: tcp udp source-address: RFC1918 deny-all-except: flows: - comment: Allow SSH from Alice's desktop source-address: ALICE_DESKTOP destination-port: SSH protocol: tcp # No other ingress should be permitted for VLAN40 ``` **Network Definitions:** Network and host names are defined in `def/networks.yaml`. ```yaml title="def/networks.yaml" networks: RFC1918: values: - address: 10.0.0.0/8 - address: 172.16.0.0/12 - address: 192.168.0.0/16 VLAN40: values: - address: 192.168.40.0/24 VLAN40_IF: # Interface IPs within VLAN40, excluded from ingress check values: - address: 192.168.40.0/32 - address: 192.168.40.252/32 - address: 192.168.40.253/32 - address: 192.168.40.254/32 ALICE_DESKTOP: values: - address: 192.168.10.98/32 ``` --- **Run Analysis:** Execute Invariant on your snapshot directory. ```bash $ invariant run --target /path/to/your/snapshot/ --condensed snapshot: cf2bb04f-554f-4a84-a3e0-bf12a13c0e4e outcome: All rules passed # Passing rules are listed in policy_ok $ invariant show policy_ok --json # A log of reachability checks performed appears in policy_logs $ invariant show policy_logs --json # Violations, if present, would appear in policy_violations $ invariant show policy_violations --json # Traceroutes demonstrating segmentation violations, if found, appear in policy_details $ invariant show policy_details --json ``` --- See [Access Policy](/AccessPolicy) for more details on rule types and reports. See [Output Overview](/Reference/Output/Output#access-policy-files) for access policy output file reference. --- --- title: Validate zone-to-zone connectivity using Invariant description: Use Invariant Access Policy rules to verify required and deny disallowed traffic flows between security zones (like PCI CDE, corporate networks, and VPN ingress points). --- Use Invariant Access Policy rules, combining `critical-flow` and `deny` or `deny-others`, to validate and enforce required connectivity *between* security zones while controlling other traffic. Zones can be defined by IP subnets or by network locations (interfaces). --- ### Scenario 1: IP Subnet to IP Subnet Segmentation Ensure a specific Management Server (`MGMT_SERVER`) in the Corporate VLAN (`CORP_VLAN`) can SSH into the Cardholder Data Environment (`CDE_ZONE`), but *no other* TCP/UDP traffic is allowed from `CORP_VLAN` into `CDE_ZONE`. **Network Definitions:** Define zones and hosts in `def/networks.yaml`. ```yaml title="def/networks.yaml" networks: CDE_ZONE: values: - address: 10.20.1.0/24 # Example CDE subnet CORP_VLAN: values: - address: 192.168.50.0/24 # Example Corporate subnet MGMT_SERVER: values: - address: 192.168.50.10/32 # Specific server allowed access ``` **Invariant Policy:** Define rules in `invariant/policies/cde_segmentation.yaml`. ```yaml title="invariant/policies/cde_segmentation.yaml" access-policy: - name: cde-zone-segmentation-corp comment: Enforce strict segmentation for CDE Zone from CORP_VLAN owner: security-compliance@example.com ingress-network: CDE_ZONE # Policy targets traffic *entering* the CDE_ZONE rules: - type: ingress-critical-flow comment: Allow SSH from MGMT_SERVER to CDE_ZONE source-address: MGMT_SERVER destination-port: SSH protocol: tcp - type: ingress-deny-others comment: Deny all other TCP/UDP from CORP_VLAN to CDE_ZONE within: # Scope the denial - protocol: tcp udp source-address: CORP_VLAN deny-all-except: flows: # Only exempt the specific SSH flow - source-address: MGMT_SERVER destination-port: SSH protocol: tcp ``` --- ### Scenario 2: Location (VPN Ingress) to IP Subnet Segmentation Ensure a specific application server in AWS (`AWS_APP_SERVER`, traffic entering via TGW VPN tunnels) can reach a database server in the CDE (`CDE_DB_SERVER`) over SQL ports, but *no other* traffic from the VPN ingress point can reach the CDE zone. **Location Definition:** Define the VPN ingress point in `invariant/locations/locations.yaml`. This uses the Tunnel interfaces on `border-1` from the tutorial example. ```yaml title="invariant/locations/locations.yaml" locations: AWS_TGW_VPN_INGRESS: - devices: border-1 interfaces: Tunnel1 Tunnel2 # Interfaces receiving traffic from AWS TGW ``` **Network Definitions:** Define relevant servers in `def/networks.yaml`. ```yaml title="def/networks.yaml" networks: CDE_ZONE: values: - address: 10.20.1.0/24 AWS_APP_SERVER: values: - address: 10.30.1.166/32 # Example AWS server IP CDE_DB_SERVER: values: - address: 10.20.1.207/32 # Example CDE server IP ``` **Invariant Policy:** Add rules to `invariant/policies/cde_segmentation.yaml`. ```yaml title="invariant/policies/cde_segmentation.yaml" access-policy: # ... (policy from Scenario 1) ... - name: cde-zone-segmentation-aws comment: Enforce strict segmentation for CDE Zone from AWS VPN owner: security-compliance@example.com ingress-network: CDE_ZONE # Policy targets traffic *entering* the CDE_ZONE rules: # Rule 1: Ensure required SQL flow is possible from AWS App Server - type: ingress-critical-flow comment: Allow SQL from AWS_APP_SERVER to CDE_DB_SERVER via VPN enter-interface: AWS_TGW_VPN_INGRESS # Traffic must enter here source-address: AWS_APP_SERVER destination-address: CDE_DB_SERVER destination-port: SQL # Assuming SQL service defined (e.g., TCP/1433, TCP/5432) protocol: tcp # Rule 2: Deny all other TCP/UDP traffic entering CDE *from this location* - type: ingress-deny-others comment: Deny all other TCP/UDP from AWS VPN ingress to CDE_ZONE within: # Scope the denial - protocol: tcp udp enter-interface: AWS_TGW_VPN_INGRESS # Only check traffic entering via VPN deny-all-except: flows: # Only exempt the specific SQL flow - source-address: AWS_APP_SERVER destination-address: CDE_DB_SERVER destination-port: SQL protocol: tcp ``` --- **Run Analysis:** Execute Invariant on your snapshot directory. ```bash invariant run --target /path/to/your/snapshot/ --condensed ``` **Check Results:** Verify all rules pass across the relevant reports (`critical_flows_ok`, `policy_ok`). Violations indicate incorrect segmentation or reachability between zones/locations. ```bash # Check for critical flow violations (expect 0 rows for these rules) invariant show critical_flows_violations --json # Check for policy violations (expect 0 rows for these rules) invariant show policy_violations --json ``` --- Using named networks for IP-based zones and named locations for interface-based boundaries allows precise validation of inter-zone connectivity policies. See [Access Policy](/AccessPolicy) for more details. --- --- title: Identify when an issue was first introduced using Invariant description: Use Invariant historical snapshots and reports to pinpoint when a network configuration change caused an issue, like a critical flow violation due to an interface shutdown. --- Use Invariant snapshot history to track down the specific snapshot where a configuration change first introduced an issue. --- **Scenario:** A critical interface (`dist-1[Ethernet3]`) was shut down, triggering a minor outage. You aren't sure when the interface was first shut down. You can scan your Invariant snapshot history to locate the last snapshot where the interface was still up. ### Check the latest snapshot Observe that the interface is currently down. ```bash $ invariant show interfaces --json --network live-IAD [ { "Hostname": "dist-1", "Interface": "Ethernet3", /* ... */ "Admin_Up": false, "Active": false, "Inactive_Reason": "Administratively down" }, ] ``` ### List historical snapshots Get a list of snapshot UUIDs for your network, ordered chronologically (newest first is typical output). ```bash $ invariant snapshots --tsv --network live-IAD f17e9368-67fd-4094-b191-4da3f837eb60 2024-01-15 10:30:00 ... d1dff68d-7da6-4438-87d8-a12086073823 2024-01-15 10:00:00 ... ``` ### Scan historical snapshots Configure and use this bash script to scan for the most recent snapshot where `dist-1[Ethernet3]` was up. ```bash TARGET_HOSTNAME="dist-1" TARGET_INTERFACE="Ethernet3" NETWORK_NAME="live-IAD" # Get snapshot UUIDs, skipping the header row, newest first SNAPSHOT_UUIDS=$(invariant snapshots --tsv --network "$NETWORK_NAME" | tail -n +2 | cut -f1) LAST_GOOD_SNAPSHOT_UUID="" FIRST_BAD_SNAPSHOT_UUID="" for SNAPSHOT_UUID in $SNAPSHOT_UUIDS; do # echo "Checking snapshot: $SNAPSHOT_UUID" IS_UP=$(invariant show interfaces --snapshot "$SNAPSHOT_UUID" --json | \ jq --arg hn "$TARGET_HOSTNAME" --arg iface "$TARGET_INTERFACE" \ '.[] | select(.Interface.hostname == $hn and .Interface.interface == $iface) | .Admin_Up') if [ "$IS_UP" = "true" ]; then LAST_GOOD_SNAPSHOT_UUID=$SNAPSHOT_UUID echo "Interface $TARGET_HOSTNAME[$TARGET_INTERFACE] was UP in snapshot $LAST_GOOD_SNAPSHOT_UUID." break # Found the last good state else # This snapshot is "bad" or the interface was already down echo "Interface $TARGET_HOSTNAME[$TARGET_INTERFACE] was DOWN in snapshot $LAST_GOOD_SNAPSHOT_UUID." FIRST_BAD_SNAPSHOT_UUID=$SNAPSHOT_UUID fi done ``` Run the script: ```bash $ invariant snapshots --tsv --network live-IAD | tail -n +2 | cut -f1 # f17e9368-67fd-4094-b191-4da3f837eb60 # d1dff68d-7da6-4438-87d8-a12086073823 # c1c0a0b0-1234-5678-9abc-def012345678 # b1b2b3b4-abcd-ef01-2345-6789abcdef01 # a0a1a2a3-1111-2222-3333-444455556666 $ # Paste configured code here Interface dist-1[Ethernet3] was DOWN in snapshot f17e9368-67fd-4094-b191-4da3f837eb60. Interface dist-1[Ethernet3] was DOWN in snapshot d1dff68d-7da6-4438-87d8-a12086073823. Interface dist-1[Ethernet3] was DOWN in snapshot c1c0a0b0-1234-5678-9abc-def012345678. Interface dist-1[Ethernet3] was UP in snapshot b1b2b3b4-abcd-ef01-2345-6789abcdef01. ``` **Confirm:** Directly confirm the status of the suspected interface (`dist-1[Ethernet3]`) in both the "last good" and "first bad" snapshots using the `interfaces` report. ```bash # LAST_GOOD_SNAPSHOT_UUID shows the interface was up $ invariant show interfaces --snapshot $LAST_GOOD_SNAPSHOT_UUID --json | \ jq '.[] | select(.Interface.hostname == "dist-1" and .Interface.interface == "Ethernet3")' [ { "Hostname": "dist-1", "Interface": "Ethernet3", /* ... */ "Admin_Up": true, "Active": true, "Inactive_Reason": null, }, ] # FIRST_BAD_SNAPSHOT_UUID shows the interface was shut down $ invariant show interfaces --snapshot $FIRST_BAD_SNAPSHOT_UUID --json | \ jq '.[] | select(.Interface.hostname == "dist-1" and .Interface.interface == "Ethernet3")' [ { "Hostname": "dist-1", "Interface": "Ethernet3", /* ... */ "Admin_Up": false, "Active": false, "Inactive_Reason": "Administratively down" }, ] ``` See [API > CLI](/API/CLI) for complete CLI documentation and [Output Overview](/Reference/Output/Output) for details on available reports. --- --- title: Create an API Token --- API Tokens are long-lived refresh tokens used for authenticating the Invariant CLI, SDK, or direct API calls for automation. --- To create an API Token using the Invariant UI: 1. Navigate to `Settings` in the top navigation bar. 2. Scroll down to the **API Tokens** section. 3. Click **Create API Token**. 4. Provide a **Token Name** and an optional **Description** to help identify the token's purpose. 5. Click **Create API Token**. :::warning Important Copy the generated API Token immediately and store it securely (e.g., in a secret manager). **It will not be shown again.** ::: --- See the [Authentication Introduction](/reference/api/introduction) for details on using API tokens. --- --- title: Authenticate using an API Token to Invariant --- swGenerate an API token from the Invariant Web UI under `Settings -> API Tokens`. See [Create an API token](/Guides/Automation-and-API/API-Tokens/create-an-api-token). :::warning Important Always store Invariant API Tokens in a secure location, such as a secret manager, to prevent unauthorized access. Avoid hardcoding tokens directly into your codebase or sharing them in public repositories. Properly managing API tokens helps protect your organization’s data and ensures compliance with security best practices. ::: --- ## Use Environment Variables Export the token and your organization name as environment variables which the `invariant` CLI will read. ```bash export INVARIANT_API_TOKEN= export INVARIANT_ORGANIZATION_NAME= # Example: Run analysis and get condensed output invariant run --condensed ``` Environment variables can also be provided on the same line as the command. ```bash INVARIANT_API_TOKEN= INVARIANT_ORGANIZATION_NAME= \ invariant run --condensed ``` --- ## Use Auth File Invariant can read the API token from `~/.invariant_creds`. ```bash # Create a credentials file at the default location echo '{"INVARIANT_API_TOKEN": "", "INVARIANT_ORGANIZATION_NAME": ""}' > ~/.invariant_creds chmod 600 ~/.invariant_creds ``` ```bash invariant run --condensed ``` If your system does not have a home directory, Invariant will fall back to .invariant_creds in the current working directory. --- See [Settings](/Reference/Settings) and [CLI Reference](/Reference/CLI) for details. See also [REST API](/reference/api/introduction) which also describes API Token usage. --- --- title: Revoke an API Token --- Revoking an API Token instantly and permanently invalidates it, preventing any further authentication using that token. --- To revoke an API Token using the Invariant UI: 1. Navigate to `Settings` in the top navigation bar. 2. Scroll down to the **API Tokens** section. 3. Locate the API Token you wish to revoke in the list. 4. Click the **Revoke** button (or trash icon) associated with that token. 5. Confirm the revocation when prompted. --- Once revoked, the token cannot be recovered or reactivated. See the [Authentication Introduction](/reference/api/introduction) for more details. --- --- title: Add a Notification Group to Invariant --- Notification Groups define recipients for alerts when violations occur in monitored networks. --- ### Using the UI 1. Navigate to **Settings > Notification Groups**. 2. Click **Add Notification Group**. 3. Enter a name, email addresses, and select networks to subscribe to. 4. Click **Create Notification Group**. --- --- title: Configure Live Network Alerts --- Invariant automatically generates alerts when an uploaded snapshot has rule violations. To receive alerts when you are regularly syncing live network snapshots with Invariant, subscribe a Notification Group to the target network and specify the email address(es) to notify. --- ### Using the UI 1. Navigate to **Settings > Notification Groups**. 2. Click **Add Notification Group**. 3. Enter a group name and add target email addresses. Select the network where live network snapshots are sent. 4. Click **Create Notification Group**. --- --- title: Build a Zero Trust deployment backlog using Invariant description: Use unenforced deny-others rules in Invariant to identify existing traffic flows for Zero Trust policy creation. --- Use Invariant `deny-others` rules with `enforce: false` to identify permitted traffic flows into or out of a network segment that do not match your minimum access requirements. The resulting `policy_violations_unenforced` report serves as a backlog of flows that need to be explicitly allowed in your Zero Trust policy or blocked by network configuration. --- **SSH Access:** To our knowledge, only certain hosts should be permitted to access SSH in the DATACENTER network (`172.16.50.0/24`). Create a policy file with a strict `deny-others` rule set to `enforce: false`. Scope it (`within`) to the traffic you want to control (here, SSH). ```yaml title="invariant/policies/zero_trust_backlog.yaml" access-policy: - name: zero-trust-datacenter-backlog comment: Identify all TCP/UDP ingress flows to Datacenter for Zero Trust policy owner: security-team@example.com enforce: false # <--- This makes this policy unenforced ingress-network: DATACENTER rules: - type: ingress-deny-others comment: Identify all internal SSH traffic which can reach the Datacenter within: - protocol: tcp destination-port: SSH deny-all-except: flows: - comment: Known business requirement source-address: MGMT_SERVER destination-port: SSH protocol: tcp ``` ```yaml title="def/networks.yaml" networks: DATACENTER: values: - address: 172.16.50.0/24 MGMT_SERVER: values: - address: 192.168.50.10/32 ``` --- **Run Invariant Analysis:** ```bash invariant run --target /path/to/your/snapshot/ ``` **4. Generate the Backlog:** Use `invariant show` to view the `policy_violations_unenforced` report. This lists all traffic flows permitted by your current network configuration that are *not* explicitly allowed in your `deny-all-except` list. This is your Zero Trust backlog. ```bash # View the backlog report as JSON invariant show policy_violations_unenforced --json # View the backlog as TSV invariant show policy_violations_unenforced --tsv ``` ### Understanding the `policy_violations_unenforced` Report (Your Zero Trust Backlog) When using an `ingress-deny-others` or `egress-deny-others` rule with `enforce: false`, the `policy_violations_unenforced` report acts as a discovery tool. It does not indicate network errors or failures. Instead, it meticulously lists every specific traffic flow that your current network configuration allows *into* (for ingress) or *out of* (for egress) the target network (`ingress-network` or `egress-network`), but which is *not* explicitly permitted within the `deny-all-except.flows` section of your unenforced rule. Think of it as Invariant saying, "Based on your network's current state (routing, ACLs, etc.), these flows *can* happen. You haven't explicitly allowed them in your Zero Trust rule yet. Do you want to?" Each item in this report represents one such flow, providing the details needed to decide whether to formally allow it in your policy or block it in your network configuration. ```json title="policy_violations_unenforced.json" [ { "index": 0, "ok": false, // ok: false means Invariant found a flow that can reach the DATACENTER network // that is not permitted in `deny-all-except`. // This is exactly what we want for backlog generation. "skipped": false, "enforce": false, // Invariant won't generate alerts or mark the snapshot as failing // Sections policy, rule, and resolved_as re-iterate your rule specification "policy": { "name": "zero-trust-datacenter-backlog", "comment": "Identify all TCP/UDP ingress flows to Datacenter for Zero Trust policy", "owner": "security-team@example.com", "ingress-network": { "list": [ "DATACENTER" ], "object": null } }, "rule": { "type": "ingress-deny-others", "comment": "Identify all internal SSH traffic which can reach the Datacenter", "within": [ { "protocol": ["tcp"], "destination-port": ["SSH"] } ], "deny-all-except": { "flows": [ { "comment": "Known business requirement", "source-address": ["MGMT_SERVER"], "destination-port": ["SSH"], "protocol": ["tcp"] } ] } }, // This shows how Invariant interpreted the rule's addresses/port names "resolved_as": [ { "destination_address": [ "172.16.50.0/24" ], "destination_port": [ "tcp/22" ], "protocol": [ "tcp" ], "source_address": [ "192.168.10.98/32" ] } ], "within_resolved_as": [ { "destination_address": null, "destination_port": [ "tcp/22" ], "protocol": [ "tcp" ], "source_address": [ "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16" ] } ], "violations": 1, // How many unique issues were found "checks": 5, // How many searches were performed behind the scenes by the tool "flow_str": "tcp src_ip=192.168.10.98 dst_ip=172.16.50.1 dst_port=22", // flow_str is the violation flow: // - Protocol: tcp // - Source IP: 192.168.10.98 (ALICE_DESKTOP in this example) // - Destination IP: 172.16.50.1 (part of DATACENTER) // - Destination Port: 22 (SSH) "start": "@enter(dist-1[Vlan10])", // "start" specifies where the violation flow originates in the model // - Device: dist-1 // - Interface: Vlan10 // - @enter(...): this is traffic entering dist-1 through interface Vlan10 "traces": [ // A detailed array of hops showing how the packet traverses the network, // including routing decisions and ACL evaluations at each step. { "disposition": "ACCEPTED", // Indicates this trace was successfully delivered "hops": [ // Virtual traceroute details ], } ] } ] ``` **Tips:** 1. **Focus on `flow_str`:** This traffic flow is currently possible but not allowed by your `deny-all-except.flows` list. In our example, it's SSH from `192.168.10.98` (Alice's Desktop) to `172.16.50.1` in the Datacenter. 2. **Understand the path with `traces`:** The `traces` section shows a path the packet could take and which ACLs and which routes facilitated it. This helps you understand *why* this flow is allowed by your current network configuration. For example, an ACL on a router might have a permissive rule allowing this specific SSH connection, or maybe there's no ACL blocking it at all along a path you did expect. 4. **Understand `start`:** This indicates the entry point of the flow into the network model, helping you contextualize its origin. --- **Workflow:** For every flow (`flow_str`) identified in this report, work with your team to determine if it represents a real business requirement or it can be closed. **If required:** Update the the `deny-all-except.flows` list and re-run the analysis tool. **If not required:** Remediate the issue in your network configuration. **Iterative Process:** Once the report is empty, you can change `enforce: false` to `enforce: true` to activate your Zero Trust policy segment. :::caution Important Invariant finds *examples* of flows not allowed by your rules. Resolving one finding may reveal additional violations not initially included in the violation search. ::: --- --- sidebar_position: 10 --- # Supported Platforms Invariant supports all platforms supported by Batfish. A listing of those platforms is provided in the following table. Please refer to the following pages on the Batfish documentation for additional information: The [Batfish official documentation](https://batfish.readthedocs.io/en/latest/formats.html) provides intructions on how to retrieve configs from each platform. ## Table of supported platforms | Platform | Support | |--------------------|-----------------| | A10 | Yes | | Arista | Yes | | Aruba | Limited | | AWS | Yes | | Check Point | Yes | | Cisco ASA | Yes | | Cisco IOS | Yes | | Cisco IOS-XE | Yes | | Cisco IOS-XR | Yes | | Cisco NX-OS | Yes | | Cumulus | Yes | | Dell Force10 | Limited | | F5 BIG-IP | Yes | | Fortinet | Yes | | Foundry | Limited | | Free-Range Routing | Yes | | iptables | Yes(hosts only) | | Juniper JunOS | Yes | | Juniper EX | Yes | | Juniper MX | Yes | | Juniper PTX | Yes | | Juniper QFX | Yes | | Juniper SRX | Yes | | Juniper T-Series | Yes | | Palo Alto Networks | Yes | | SONiC | Yes | --- --- sidebar_position: 20 --- # Snapshots ## Packaging your snapshot Invariant will look for input files in specific directories relative to your snapshot directory. A quick overview of the directory structure: ```bash snapshot/ # Root directory of snapshot. aws_configs/ # AWS JSON files. batfish/ # Batfish configuration files. configs/ # On-premise device configurations (Cisco, Juniper, Arista, Fortinet, etc). def/ # Human-friendly name to IP mappings. hosts/ # Host model files including iptables. invariant/ # locations/ # Human-friendly name to device and interface mappings. policies/ # Policy files to be applied to this network. probe_targets.yaml # Connectivity probe configuration file. ``` ## AWS configuration directory Invariant is able to model your AWS VPC network and associated resources just like your on-premise network. You must supply the AWS JSON description files for each resource you wish to model. All AWS JSON files must be places in the `aws_configs` directory to be recognized. ### Retrieving AWS resources The JSON files can be retrieved by through several methods: - Using the AWS CLI. - Using the boto3 client in Python. To use the AWS CLI to fetch JSON files for VPCs: ```bash aws ec2 describe-vpcs ``` To use the Python boto3 client to fetch JSON files for VPCs: ```python import boto3 ec2_client = boto3.client('ec2') response = ec2_client.describe_vpcs() ``` :::note The boto3-based Python script [bf-aws-snapshot](https://github.com/ratulm/bf-aws-snapshot) will quickly collect all required AWS JSON files. ::: ### AWS folder organization In AWS your resources may be spread across multiple accounts and regions. If this is the case you must organize your resources in the `aws_configs` by accounts and then regions. If you do not use multiple accounts or regions, you can omit the respective directory level. #### Examples Two accounts with two regions in each. ```bash aws_configs/ account_1/ us-east-2/ us-west-2/ account_2/ us-east-2/ us-west-2/ ``` The following two directory examples are equivalent for one account with one region ```bash aws_configs/ account_1/ us-east-2/ ``` ```bash aws_configs/ ``` ## Batfish ### ISP Schema When creating your network you may wish to model the network outside of it such as the Internet. The ISP configuration file provides you this ability. You will need to create a file in the batfish directory named `isp_config.json`. | Field | Type | Description | |------------------------------------------------|-------------------------------------|-------------------------------------------------------------------------------------------------------------------------| | `bgpPeers[].hostname` | string | Hostname of the BGP peer. | | `bgpPeers[].ispAttachment.hostname` | string | Optional: Hostname of the attached ISP Peer. | | `bgpPeers[].ispAttachment.interface` | string | Interface of the attached ISP Peer. | | `bgpPeers[].ispAttachment.vlanTag` | integer | Optional: Dot1q encapsulation tag. | | `bgpPeers[].ispAttachment` | object | Optional: Attached ISP information. | | `bgpPeers[].peerAddress` | string | IP address of the BGP peer in `xxx.xxx.xxx.xx` format. | | `bgpPeers[].vrf` | string | Optional: VRF on the host. If left unspecified, default VRF is used. | | `bgpPeers` | list of objects | List of BGP peers connected. Use for more complex BGP connections. | | `borderInterfaces[].borderInterface.hostname` | string | Hostname of the border interface. | | `borderInterfaces[].borderInterface.interface` | string | Hostname of the border interface. | | `borderInterfaces[].borderInterface` | object | Object representing a single border interface. | | `borderInterfaces` | list of objects | List of layer 3 border interfaces connected directly to ISP. | | `filter.onlyRemoteAsns` | list of integers | List of ASNs that are not filtered out of the model. | | `filter.onlyRemoteIps` | list of strings | List of IPs that are not filtered out of the model. IPs are in the format `xxx.xxx.xxx.xxx`. | | `ispNodeInfo[].asn` | integer | Autonomous System Number (ASN) of the ISP. | | `ispNodeInfo[].name` | string | Name of the ISP node. | | `ispNodeInfo[].role` | enum(`TRANSIT`, `PRIVATE_BACKBONE`) | Role of the ISP node. `TRANSIT`: Models Internet ISP providers. `PRIVATE_BACKBONE`: Models a private peering connection | | `ispNodeInfo` | object | List of ISP nodes providing access outside of the network. | | `ispPeerings[].ispPeer.peer1.asn` | integer | ASN of first peer. | | `ispPeerings[].ispPeer.peer2.asn` | integer | ASN of second peer. | | `ispPeerings[].ispPeer` | object | A pairing of ISP nodes | | `ispPeerings` | object | Allows for peering between ISP nodes. | #### Example The following is an example from our [codelab](https://github.com/InvariantTech/codelab_solution/blob/main/batfish/isp_config.json) It connects the codelab network to the Internet via two ISP nodes. ```json { "borderInterfaces": [ { "borderInterface": { "hostname": "border-1", "interface": "GigabitEthernet0/1" } }, { "borderInterface": { "hostname": "border-1", "interface": "GigabitEthernet0/3" } } ], "ispNodeInfo": [ { "asn": 64501, "name": "ISP1", "role": "TRANSIT" }, { "asn": 64502, "name": "ISP2", "role": "TRANSIT" } ] } ``` ## On-premise configurations directory On premise devices must be located under `snapshot/configs/`. The directory is recursed and all files are attempted to be loaded. Organizing the configurations into folders is supported. ### Supported on-premise devices * A10 * Arista * Cisco * IOS * IOS-XE * IOS-XR * NX-OS * ASA * Check Point * Cumulus Linux * F5 Big IP * Fortinet * Juniper * EX * MX * PTX * QFX * SRX * T-Series * Palo Alto Networks * SONiC ## Definitions directory The definitions directory contains one or more definition files. These files are YAML and are the same as [Aerleon Definitions](https://aerleon.readthedocs.io/en/latest/getting_started/#definition-files) | Field | Type | Description | |--------------------------------------------|-----------------|----------------------------------------------------------------------| | `networks` | list of objects | List of network groups and associated values (subnets and addresses) | | `networks[].group_name` | string | Name of the network group | | `networks[].group_name.values` | list | List of address and comment pairs, or network group references | | `networks[].group_name.values[].address` | string | IP address or subnet in CIDR notation | | `networks[].group_name.values[].comment` | string | Optional comment for the address | | `networks[].group_name.values[].group_ref` | string | Reference to another network group | | Field | Type | Description | |---------------------------------------|-----------------|------------------------------------------------------------| | `services` | list of objects | List of service definitions, including ports and protocols | | `services[].service_name` | string | Name of the service or service group | | `services[].service_name.protocol` | string | Protocol used by the service (e.g., tcp, udp) | | `services[].service_name.port` | string | Port number or range used by the service | | `services[].service_name.service_ref` | string | Reference to another service or service group | We inject ports that are [registered with the IANA](https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml). You can use any registered name in capital letters. For example, ssh is defined in IANA as port 22 on tcp, udp, and sctp. Use the service name SSH in this case. ## Hosts directory You are able to model hosts on the network by including JSON files in the `snapshot/hosts` directory. Each host is a file in JSON format and can have multiple interfaces. You can include a reference to IPTables applied to the host. | Field | Type | Description | |-----------------------------------------|--------|-----------------------------------------------------------------| | `hostname` | string | Name of the host. | | `iptablesFile` | string | Path to an IPTables file to be applied to the host. | | `hostInterfaces` | object | A set of key names to hostInterface objects. | | `hostInterfaces.interface_name` | object | interface_name is a user supplied key to the interface objects. | | `hostInterfaces.interface_name.name` | string | Name of the interface. | | `hostInterfaces.interface_name.prefix` | string | IP of interface in CIDR notation. | | `hostInterfaces.interface_name.gateway` | string | IP of the gateway. | An example host file with IPtables and a single interface is below. ```bash { "hostname" : "host1", "iptablesFile" : "iptables/host1.iptables", "hostInterfaces" : { "eth0" : { "name": "eth0", "prefix" : "10.0.0.20/24" "gateway": "10.0.0.1 } } } ``` ## Locations directory You can create locations by creating yaml files in the `snapshot/invariant/locations` directory. Locations allow you to reference a specific interface and host for traffic flows. There is one location that is *required* and that is EXTERNAL. EXTERNAL is used for Invariant to determine where the external boundary of your network is. Forgetting this file will result in an error. ```yaml locations: EXTERNAL: - devices: border-1 interfaces: GigabitEthernet0/1 - devices: border-1 interfaces: GigabitEthernet0/3 ``` ## Policies directory Policy files are YAML files that live in `snapshot/invariant/policies`. The directory is recursed for all YAML files. You can use folders and file names to help organize your policies. Each file can have multiple access policies inside. See [Access Policy](Access_Policy) for schema and reference information. ## Probe targets Probe targets are located in a file `snapshot/invariant/probe_targets.yaml` and allow you to create simple targets for conectivity tests. This is very useful when first onboarding your network snapshots. | Field | Type | Description | |----------------------------------|-----------------|-----------------------------------------------| | `probe_targets` | list of objects | List of probe target objects. | | `probe_targets[].comment` | string | Comment describing the probe. | | `probe_targets[].target` | string | Definition network to target for probing. | | `probe_targets[].type` | string | Type of probe, either tcp, udp, or icmp-echo. | | `probe_targets[].ignore-filters` | boolean | Should this probe ignore firewall filtering. | Example probe targeting both Cloudflare and Google DNS servers. ```yaml probe_targets: - comment: Custom probe - use both UDP and ICMP ECHO target: CLOUDFLARE_DNS GOOGLE_DNS type: icmp-echo udp ignore-filters: False ``` --- --- sidebar_position: 30 --- # Access Policy An access policy does the following. * Defines the type of rules allowed, ingress or egress. * Defines the network(s) on one side of the test * `ingress-network` defines the destination addresses. * `egress-network` defines the source addresses. * Provides organizational metadata such as names, comments, and owners. Rules evaluations happen independently, so overlapping policies and rules are allowed. ## Access policy A policy is a group of related rules that target the same ‘ingress’ or ‘egress’ network. You must place Invariant rules inside an access policy. ### Example ```yaml access-policy: - comment: Access to the datacenter is controlled by this policy ingress-network: DATACENTER name: datacenter-security-policy owner: neteng@company.com rules: - comment: VLAN30 must not be able to reach DATACENTER through SSH destination-port: SSH protocol: tcp source-address: VLAN30 type: ingress-deny ``` ### Schema | Field | Type | Required? | Description | |-----------------------------------|-----------------------------------------------|---------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------| | `access-policy[].comment` | string | Optional | Free form comment describing the policy. | | `access-policy[].owner` | string | Optional | String to record owner of the policy. e.g., `network-team@company.com` or `security team` | | `access-policy[].enforce` | boolean | Optional | Boolean indicating the policy enforcement, resulting in a violation. Defaults to true. | | `access-policy` | list of objects | Required | List of access policies. | | `access-policy[].name` | string | Required | Name of the policy. No whitespace is allowed. e.g. `my-access-policy` or `my_access_policy`. Only characters -, _, A-Z, a-z, 0-9 are allowed. | | `access-policy[].rules` | list of objects | Required | A list of rule objects. | | `access-policy[].ingress-network` | list of strings or [Network](#network-schema) | Yes (mutually exclusive to egress-network) | Network definitions of the destination networks or an `ingress-network` object. Mutually exclusive with `egress-network`. | | `access-policy[].egress-network` | list of strings or [Network](#network-schema) | Yes (mutually exclusive to ingress-network) | Network definitions of the egress networks or a `egress-network` object. Mutually exclusive with `ingress-network`. | ### Policy best practices * Use comments to help describe the policy's intention and refer to external resources such as service tickets. * Use teams rather than individuals in the owner's field as people move teams or companies. * Set `enforce` to false during the development of new policies or when you want to track your progression towards adhering to policy. ## Network schema A policy must have an ‘ingress-network’ or ‘egress-network’ and never both. All rules in this policy must match the direction of the policy. A policy with ‘ingress-network’ defined may only contain ‘ingress’ rules. A policy with ‘egress-network’ defined may only contain ‘egress’ rules. | Field | Type | Required? | Description | |-----------------------|-----------------|-------------------------|---------------------------------------------------------------------| | `destination-address` | list of strings | Required (at least one) | Network definitions of the destination networks. | | `destination-exclude` | list of strings | Required (at least one) | Network definitions that are subtracted from `destination-address`. | | Field | Type | Required? | Description | |--------------------|-----------------|-------------------------|---------------------------------------------------------------------------------------------| | `source-address` | list of strings | Required (at least one) | Network definitions of the source networks. | | `source-exclude` | list of strings | Required (at least one) | Network definitions that are subtracted from `source-address`. | | `source-interface` | list of strings | Optional | Consider traffic entering on these interfaces. Disables automatic interface selection. | | `enter-interface` | list of strings | Optional | Consider traffic originating from these interfaces. Disables automatic interface selection. | ## Rule types Invariant supports the following types of rules. | Rule type | Direction | Description | |-----------------------|-----------|--------------------------------------------------------------------------------------------------------------| | ingress-critical-flow | ingress | This traffic should *always* be successfully delivered. | | egress-critical-flow | egress | This traffic should *always* be successfully delivered. | | ingress-deny | ingress | This traffic should *never* be successfully delivered. | | egress-deny | egress | This traffic should *never* be successfully delivered. | | ingress-deny-others | ingress | Within a scope (e.g., TCP traffic), traffic should *never* be successfully delivered except where permitted. | | egress-deny-others | egress | Within a scope (e.g., TCP traffic), traffic should *never* be successfully delivered except where permitted. | ## Rules schema | Field | Type | Required? | Description | |-------------------------|------------------|----------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `type` | string | Required | The type of rule, can be `ingress-critical-flow`, `egress-critical-flow`, `ingress-deny`, `egress-deny`, `ingress-deny-others`, `egress-deny-others`. | | `comment` | string | Optional | Free form text describing the rule. | | `source-address` | list of strings | Optional | Network definitions of the source networks. | | `source-exclude` | list of strings | Optional | Network definitions that are subtracted from `source-address`. | | `source-port` | list of strings | Optional | Service definitions used as the source ports. | | `source-interface` | list of strings | Optional | Interface identifiers where traffic should be sourced from. | | `enter-interface` | list of strings | Optional | Interface identifiers where traffic should enter. | | `destination-address` | list of strings | Optional | Network definitions of the destination networks. | | `destination-exclude` | list of strings | Optional | Network definitions that will be subtracted from `destination-address`. | | `destination-port` | list of strings | Optional | Service definitions used as the destination ports. | | `protocol` | list of strings | Optional | Protocol such as `tcp`, `udp` or `icmp` the rule covers. | | `icmp-type` | list of integers | Optional | ICMP type numbers, used with the protocol being `icmp`. See [IANA documentation](https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml) for list of types | | `icmp-code` | list of integers | Optional | ICMP code numbers, used with the protocol being `icmp`, must fall within the valid codes for the type. See [IANA documentation](https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml) for list of codes | | `within` | list of Flows | Optional | Used when type is `ingress-deny-others` or `egress-deny-others`. Scopes deny-other search space. | | `deny-all-except.flows` | list of Flows | Required with `deny-others` type | Flows that are exempt from violation for `ingress-deny-others` or `egress-deny-others` | ### Rules best practices * Use comments to describe the intent behind the rule. * If you want to ensure flows in `deny-all-except.flows` are allowed, use a critical flow in tandem. ### Flow schema | Field | Type | Required? | Description | |-----------------------|--------|-----------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `comment` | string | Optional | Free form text describing the rule. | | `source-address` | string | Optional | Network definitions of the source networks. | | `source-exclude` | string | Optional | Network definitions that will be subtracted from `source-address`. | | `source-port` | string | Optional | Service definitions used as the source ports. | | `source-interface` | string | Optional | Interface identifiers where traffic should be sourced. | | `enter-interface` | string | Optional | Interface identifiers where traffic should enter. | | `destination-address` | string | Optional | Network definitions of the destination networks. | | `destination-exclude` | string | Optional | Network definitions that will be subtracted from `destination-address`. | | `destination-port` | string | Optional | Service definitions used as the destination ports. | | `protocol` | string | Optional | Protocol such as `tcp`, `udp` or `icmp` the flow covers. | | `icmp-type` | string | Optional | ICMP type numbers, used with the protocol being `icmp`. See [IANA documentation](https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml) for list of types | | `icmp-code` | string | Optional | ICMP code numbers, used with the protocol being `icmp`, must fall within the valid codes for the type. See [IANA documentation](https://www.iana.org/assignments/icmp-parameters/icmp-parameters.xhtml) for list of codes | ### Examples #### ingress-critical-flow This rule asserts that a traffic flow will always be delivered. Specifically, it looks for any possible way a packet could be rejected, dropped, or failed to route within this traffic class. ```yaml access-policy: - name: dmz-ingress comment: | This policy asserts that the DMZ network makes some services available to the internet. owner: example@example.com ingress-network: DMZ rules: - type: ingress-critical-flow comment: Ensure public HTTP/HTTPS access to DMZ resources protocol: tcp udp destination-port: HTTP HTTPS ``` #### egress-critical-flow Identical to ingress-critical-flow. Asserts that traffic flows between the `egress-network` and the `destination-address` are always delivered. Specifically this rule looks for any possible way a packet could be rejected, dropped, or fail to route within this traffic class. ```yaml access-policy: - name: basic-internet-access comment: | This policy asserts that some basic internet access (egress) is expected for the target networks. owner: example@example.com egress-network: - DMZ - VLAN30 - CLIENT_VLANS rules: - type: egress-critical-flow comment: Ensure access to 1.1.1.1, 8.8.8.8 etc protocol: tcp udp destination-address: GOOGLE_DNS CLOUDFLARE_DNS LEVEL3_DNS destination-port: DNS - name: dmz-access-needed comment: | This policy encodes critical dependencies for the DMZ network owner: example@example.com egress-network: DMZ rules: - type: egress-critical-flow comment: Ensure DMZ servers can send telemetry into the protected SEC_LOGS network protocol: tcp udp destination-address: SEC_LOGS destination-port: HTTPS ``` #### ingress-deny It asserts that a traffic flow can never be successfully delivered. Specifically, this rule looks for any possible way a packet could be successfully delivered within this class of traffic. ```yaml access-policy: - name: ingress-no-ssh comment: | This blanket policy asserts SSH access is denied for any traffic entering from the internet. owner: example@example.com ingress-network: RFC1918 DMZ rules: - type: ingress-deny comment: Ensure public SSH access is denied protocol: tcp udp enter-interface: EDGE_FROM_INTERNET destination-port: SSH ``` #### egress-deny Identical to ingress-deny. Asserts that traffic flows from `MALICIOUS_PUBLIC_IPS` to `RFC1918` can never be successfully delivered. Specifically, this rule looks for any possible way a packet could be successfully delivered within this class of traffic. ```yaml access-policy: - name: egress-malicious-nets comment: | This blanket policy asserts outbound access is denied to certain malicious networks. owner: example@example.com egress-network: RFC1918 rules: - type: egress-deny comment: Ensure outbound access to malicious networks is not allowed protocol: tcp udp destination-address: MALICIOUS_PUBLIC_IPS ``` #### ingress-deny-others This rule asserts that traffic can never be successfully delivered to the target network except for specific permitted flows. It looks for how a forbidden packet could be successfully delivered. The optional ‘within’ field restricts the scope of the rule. Although the field is optional, almost all deny-others rules will need to be restricted by protocol. There are two reasons for this: Not all IP protocols support ports. Rules that use destination-port or source-port must use ‘within’ to restrict the rule scope to IP protocols supporting ports (e.g., TCP, UDP). Many users are focused on TCP and UDP access policies and are not prepared to establish policies for other IP protocols. When reasoning about deny-others rules, it can be helpful to treat the rule as a boolean expression: IF traffic matches the network section AND traffic matches the ‘within’ section AND traffic is NOT in the ‘deny-all-except’ list THEN the traffic violates the rule. ```yaml access-policy: - name: dmz-ingress comment: example owner: example@example.com ingress-network: DMZ rules: - type: ingress-deny-others comment: Limit SSH access to only from bastion network within: - protocol: tcp destination-port: SSH deny-all-except: flows: - comment: Internal SSH access source-address: BASTION destination-port: SSH protocol: tcp ``` #### egress-deny-others Identical to ingress-deny-others. Asserts that traffic flows between `egress-network` and `destination-address` can never be successfully delivered to the target network except for specific permitted flows. This rule looks for how a forbidden packet could be successfully delivered. See ingress-deny-others for more information. ```yaml access-policy: - name: client-egress comment: | This policy asserts that traffic entering the CLIENT_BORDER interfaces can reach only necessary resources on the network. It targets the CLIENT_BORDER interfaces directly to ensure the policy applies even to spoofed source addresses. owner: example@example.com egress-network: enter-interface: CLIENT_BORDER rules: - type: ingress-deny-others comment: Limit TCP/UDP access to DMZ network, external only within: - protocol: tcp udp deny-all-except: flows: - comment: Client - DMZ destination-address: DMZ destination-port: HTTP HTTPS SSH - comment: Client - NTP destination-address: NTP destination-port: NTP - comment: Client - DNS destination-address: DNS destination-port: DNS - comment: Client - External destination-exclude: RFC1918 DMZ ``` --- --- sidebar_position: 10 --- # Output Overview Invariant creates a set of reports for each network snapshot it analyzes. These files can be accessed using the [`invariant show `](/Reference/CLI#show) command. By default, the `show` command displays the file as an interactive table, but it can also output the file as TSV or JSON. ```bash # Collect the violations summary table as JSON and TSV invariant show --json policy_violations > policy_violations.json invariant show --tsv policy_violations > policy_violations.tsv # View the olations summary table invariant show policy_violations # +----+---------+-------+-----------+------------------------------------------------------------------------------------------------------------------------------------------------------> # | | index | ok | skipped | policy > # |----+---------+-------+-----------+------------------------------------------------------------------------------------------------------------------------------------------------------> # | 0 | 4 | False | False | {'comment': 'Access that the staff vlan has.', 'egress-network': {'list': None, 'object': {'source-address': array(['VLAN30'], dtype=object), 'source> # +----+---------+-------+-----------+------------------------------------------------------------------------------------------------------------------------------------------------------> ``` ## Accessing Prior Snapshots By default, the `show` command accesses the most recent snapshot evaluated by the current CLI session. You can access prior snapshot files using the `--snapshot` flag. ```bash # Check if the most recent live scan has any violations export LAST_SCAN_SNAPSHOT=$(invariant snapshots --tsv --network live_scans | head -2 | tail -1) invariant show --json --snapshot $LAST_SCAN_SNAPSHOT | jq '.summary.policy_violations' # 0 invariant show --json --snapshot $LAST_SCAN_SNAPSHOT | jq '.summary.critical_flows_violations' # 1 ``` The [Output Files](#output-files) section below describes how to interpret the number of rows in each report. ## Automation The `invariant run --condensed` switch produces very terse output which may be helpful in basic automation and scripting scenarios. ```bash invariant run --condensed # snapshot: cf2bb04f-554f-4a84-a3e0-bf12a13c0e4e # outcome: Rule violations found ``` The condensed output will always write two lines to stdout: the first containing the snapshot ID and the second containing the outcome. Another approach would be to use `invariant run --json`. This output mode includes the snapshot ID and the row count for each report. Both of these scenarios allow you to programmatically determine if a violation was found and get the snapshot ID for further examination. ```bash invariant run --json > invariant_run.json # Test whether there were any violations in the last run jq .summary.policy_violations invariant_run.json # 1 jq .summary.critical_flows_violations invariant_run.json # 0 # Fetch the violations summary table using the snapshot ID invariant show --json --snapshot $(jq -r .report.uuid invariant_run.json) policy_violations > policy_violations.json ``` Automation scenarios will use an API token. The API token can be provided to the invariant program through the environment variable `INVARIANT_API_TOKEN`. The organization name is also required - this can be found in quickly by logging in and examining the URL: notice `5678` in `https://app.prod.invariant.tech/5678/p/main/network/`. ```bash export INVARIANT_API_TOKEN= export INVARIANT_ORGANIZATION_NAME=1234 invariant run ``` When using an API token, the `invariant show` command will require the `--snapshot` option. See the examples above for ways to reliably get the snapshot ID from `invariant run`. ## Output Files ### Access Policy Files This section appears if one or more access policy rules were included in the snapshot. These reports describe the pass/fail status of each rule, example virtual traceroutes, and relevant traffic flows. | File | Description | Rows Correspond To | |------|------|------| | [critical_flows_ok](AccessPolicy/critical_flows_ok) | Passing critical flow rules. | Number of passing critical flow rules. | | [policy_ok](AccessPolicy/policy_ok) | Passing access policy rules. | Number of passing access policy rules. | | [critical_flows_violations](AccessPolicy/critical_flows_violations) | Failing critical flow rules. | Number of failing critical flow rules (enforced rules only). | | [critical_flows_violations_unenforced](AccessPolicy/critical_flows_violations_unenforced) | Failing critical flow rules. | Number of failing critical flow rules (unenforced rules only). | | [policy_violations](AccessPolicy/policy_violations) | Failing access policy rules. | Number of failing access policy rules (enforced rules only). | | [policy_violations_unenforced](AccessPolicy/policy_violations_unenforced) | Failing access policy rules. | Number of failing access policy rules (unenforced rules only). | | [critical_flows_skipped](AccessPolicy/critical_flows_skipped) | Invalid critical flow rules. | Number of invalid critical flow rules. | | [critical_flows_logs](AccessPolicy/critical_flows_logs) | Processing summary for critical flow rules. | Number of critical flow rules. | | [policy_skipped](AccessPolicy/policy_skipped) | Invalid access policy rules. | Number of invalid access policy rules. | | [policy_logs](AccessPolicy/policy_logs) | Processing summary for access policy rules. | Number of access policy rules. | | [critical_flows_details](AccessPolicy/critical_flows_details) | Traces, check logs for passing and failing rules. | Number of traces or checks - possibly more than one per rule. | | [policy_details](AccessPolicy/policy_details) | Traces, check logs for passing and failing rules. | Number of traces or checks - possibly more than one per rule. | ### Network Information Files Complete information about the network model. | File | Description | Rows Correspond To | |------|------|------| | [nodes](NetworkInformation/nodes) | Network nodes (devices, hosts, cloud resources). | Number of nodes loaded in the model. | | [interfaces](NetworkInformation/interfaces) | Network interfaces. | Number of interfaces loaded in the model. | | [named_structures](NetworkInformation/named_structures) | Vendor-independent structures (ACLs, VXLANs, etc). | Number of abstract structures loaded in the model. | | [vlan_properties](NetworkInformation/vlan_properties) | VLANs and VXLANs.| Number of VLANs and VXLANs loaded in the model. | | [hsrp_properties](NetworkInformation/hsrp_properties) | HSRP groups. | Number of HSRP groups loaded in the model. | | [mlag_properties](NetworkInformation/mlag_properties) | MLAG domains. | Number of MLAG domains loaded in the model. | | [ip_owners](NetworkInformation/ip_owners) | IP assignments. | Number of interfaces with IP addresses assigned. | | [vrrp_properties](NetworkInformation/vrrp_properties) | VRRP groups. | Number of VRRP groups loaded in the model. | | [routes](NetworkInformation/routes) | Routing tables. | Number of routing table entries across all devices in the model. | ### Topology Files | File | Description | Rows Correspond To | |------|------|------| | [layer_3_edges](Topology/layer_3_edges) | Layer 3 edges. | Number of layer 3 edges in the model. | | [layer_1_edges](Topology/layer_1_edges) | User-provided layer 1 edges. | Number of user-provided layer 1 edges in the model. | | [edges](Topology/edges) | Layer 3 edges (duplicate). | Number of layer 3 edges in the model. | ### BGP Files | File | Description | Rows Correspond To | |------|------|------| | [bgp_process_config](BGP/bgp_process_config) | Configuration settings for BGP processes. | Number of BGP processes loaded in the model. | | [bgp_peer_config](BGP/bgp_peer_config) | Configuration settings for configured BGP peerings. | Number of configured BGP peerings loaded in the model. | | [bgp_session_compatibility](BGP/bgp_session_compatibility) | Issues found in configured BGP peerings. | Number of configured BGP peerings with issues found. | | [bgp_session_status](BGP/bgp_session_status) | Status information for configured BGP peerings. | Number of configured BGP peerings loaded in the model. | | [bgp_edges](BGP/bgp_edges) | BGP edges. | Number of BGP edges loaded in the model. | | [bgp_ribs](BGP/bgp_ribs) | BGP RIBs. | Number of BGP RIB entries across all devices in the model. | ### OSPF Files | File | Description | Rows Correspond To | |------|------|------| | [ospf_process_config](OSPF/ospf_process_config) | OSPF routing processes. | Number of running OSPF processes in the model. | | [ospf_interface_config](OSPF/ospf_interface_config) | Interface-level OSPF configuration details. | Number of interfaces running OSPF. | | [ospf_area_config](OSPF/ospf_area_config) | OSPF areas. | Number of OSPF areas in the model. | | [ospf_session_compatibility](OSPF/ospf_session_compatibility) | OSPF sessions. | Number of OSPF sessions in the model. | ### Inconsistent Traffic Files | File | Description | Rows Correspond To | |------|------|------| | [subnet_multipath](InconsistentTraffic/subnet_multipath) | Examples of traffic flows that are treated differently (i.e., dropped versus forwarded) by different paths in the network. | Number of example flows found. | | [loopback_multipath](InconsistentTraffic/loopback_multipath) | Examples of traffic flows between loopbacks that are treated differently (i.e., dropped versus forwarded) in the presence of multipath routing. | Number of example flows found. | ### Model Creation Files Files in this section illustrate how the digital twin model was created from the provided input. | File | Description | Rows Correspond To | |------|------|------| | [defined_structures](ModelCreation/defined_structures) | Structure definitions as they appear in config files (ACLs, VXLANs, etc). | Number of structure definitions found. | | [referenced_structures](ModelCreation/referenced_structures) | Structure references as they appear in config files (ACLs, VXLANs, etc). | Number of references to defined structures. | | [unused_structures](ModelCreation/unused_structures) | Structure definitions not referenced or used. | Number of unused structure definitions. | | [undefined_references](ModelCreation/undefined_references) | Structure references with no matching definition. | Number of undefined references. | | [unconnected_nodes](ModelCreation/unconnected_nodes) | Nodes with no connection to any other node in the model. | Number of unconnected nodes. | | [file_parse_status](ModelCreation/file_parse_status) | Parsing status of snapshot files. | Number of files found in the snapshot. | | [ignored_lines](ModelCreation/ignored_lines) | Lines parsed but ignored by the model. | Number of ignored lines. | | [parse_warnings](ModelCreation/parse_warnings) | Warnings that occurred when parsing snapshot files. | Number of warnings produced. | ### Errors Files | File | Description | Rows Correspond To | |------|------|------| | [errors](Errors/errors) | Errors encountered by Invariant. | Number of errors produced. | ### Probes Files | File | Description | Rows Correspond To | |------|------|------| | [probes](Probes/probes) | Quick virtual traceroutes fired from all nodes. | Number of traceroute targets. | --- --- sidebar_position: 10 --- # probes Probes are quick connectivity tests used for troubleshooting the model. By default they will be a probe from all nodes to `8.8.8.8/32` and `1.1.1.1/32` over both `ICMP` and `UDP`. | Field | Type | Description | |------------------|-----------|-----------------------------------------------------------------------------| | `target` | `IP` | Target subnet. | | `type` | `String` | Type of probe. `ICMP_ECHO`, `TCP`, or `UDP`. | | `comment` | `String` | User-provided description. | | `ignore_filters` | `Boolean` | If true, bypass all ACLs and consider routing only. | | `node_outcomes` | `JSON` | Probe outcome for every network node. `always`, `partial`, or `never`. | --- --- sidebar_position: 50 --- # critical_flows_details Detailed results for all critical flow rule tests. Includes virtual traceroutes where appropriate for both passing and failing rules. | Field | Type | Description | |----------------------|-------------------|---------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the critical flow rule. | | `ok` | `Boolean` | Did the rule pass or fail? | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `resolved_as` | `JSON` | All address and port names resolved to IP and port values. | | `errors` | `List of Strings` | List of errors generated from this rule. | | `rule_type` | `String` | The rule type. `ingress-critical-flow` or `egress-critical-flow`. | | `direction` | `String` | For violations, may be `Forward flow`, `'Return Flow (Failure)`, or `Return Flow (Inconsistent)`. | | `start` | `String` | One or more start locations tested for this traffic flow. | | `flow` | `JSON` | The initial IP packet value or range of values used in this example. | | `traces` | `JSON` | One or more virtual traceroutes for the traffic flow. | | `skipped` | `Boolean` | Was the rule skipped? | | `within` | | Not used for critical flows. | | `within_resolved_as` | | Not used for critical flows. | | `query` | | Not used for critical flows. | | `enforce` | `Boolean` | Is this rule enforced? | | `flow_str` | `String` | A descriptive summary of the 'flow' column. | --- --- sidebar_position: 60 --- # critical_flows_logs Processing summary for each critical flow rule. Rules not evaluated due to errors can be found here. | Field | Type | Description | |--------------|-------------------|---------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the critical flow rule. | | `ok` | `Boolean` | Did the rule pass or fail? | | `skipped` | `Boolean` | Was the rule skipped? | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this rule. | | `rule_type` | `String` | The rule type. `ingress-critical-flow` or `egress-critical-flow`. | | `violations` | `Integer` | Total number of unique violation examples found for this rule. | | `checks` | `Integer` | Total number of checks performed while evaluating this rule. | | `enforce` | `Boolean` | Is this rule enforced? | | `check_log` | `JSON` | A detailed list of checks used to validate the rule. | --- --- sidebar_position: 10 --- # critical_flows_ok Passing critical flow rules. | Field | Type | Description | |--------------|-------------------|---------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the critical flow rule. | | `ok` | `Boolean` | Always true. | | `skipped` | `Boolean` | Always false. | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this rule. | | `rule_type` | `String` | The rule type. `ingress-critical-flow` or `egress-critical-flow`. | | `violations` | `Integer` | Always zero. | | `checks` | `Integer` | Total number of checks performed while evaluating this rule. | | `enforce` | `Boolean` | Is this rule enforced? | --- --- sidebar_position: 40 --- # critical_flows_skipped Invalid critical flow rules. Invariant could not evalute these rules because some correction is needed. | Field | Type | Description | |--------------|-------------------|---------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the critical flow rule. | | `ok` | `Boolean` | Always false for skipped rules. | | `skipped` | `Boolean` | Always true for skipped rules. | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this rule. | | `rule_type` | `String` | The rule type. `ingress-critical-flow` or `egress-critical-flow`. | | `violations` | `Integer` | Always zero for skipped rules. | | `checks` | `Integer` | Always zero for skipped rules. | | `enforce` | `Boolean` | Is this rule enforced? | --- --- sidebar_position: 20 --- # critical_flows_violations Failing critical flow rules. Excludes rules flagged with enforce = False - see [critical_flows_violations_unenforced](critical_flows_violations_unenforced). | Field | Type | Description | |--------------|-------------------|---------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the critical flow rule. | | `ok` | `Boolean` | Always false. | | `skipped` | `Boolean` | Always false. | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this rule. | | `rule_type` | `String` | The rule type. `ingress-critical-flow` or `egress-critical-flow`. | | `violations` | `Integer` | Total number of unique violation examples found for this rule. | | `checks` | `Integer` | Total number of checks performed while evaluating this rule. | | `enforce` | `Boolean` | Always true. | --- --- sidebar_position: 30 --- # critical_flows_violations_unenforced Failing critical flow rules flagged with enforce = False. | Field | Type | Description | |--------------|-------------------|---------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the critical flow rule. | | `ok` | `Boolean` | Always false. | | `skipped` | `Boolean` | Always false. | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this rule. | | `rule_type` | `String` | The rule type. `ingress-critical-flow` or `egress-critical-flow`. | | `violations` | `Integer` | Total number of unique violation examples found for this rule. | | `checks` | `Integer` | Total number of checks performed while evaluating this rule. | | `enforce` | `Boolean` | Always false. | --- --- sidebar_position: 110 --- # policy_details Detailed results for all access control rule tests. Includes virtual traceroutes where appropriate for both passing and failing rules. | Field | Type | Description | |----------------------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the policy rule. | | `ok` | `Boolean` | Did the rule pass or fail? | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `resolved_as` | `JSON` | All address and port names resolved to IP and port values. | | `errors` | `List of Strings` | List of errors generated from this rule. | | `rule_type` | `String` | The rule type. `ingress-deny`, `egress-deny`, `ingress-deny-others`, or `egress-deny-others`. | | `direction` | `String` | The rule type, capitalized. | | `start` | `String` | One or more start locations tested for this traffic flow. | | `flow` | `JSON` | The initial IP packet value or range of values used in this example. | | `traces` | `JSON` | One or more virtual traceroutes for the traffic flow. | | `skipped` | `Boolean` | Was the rule skipped? | | `within` | `JSON` | The `within` section for `deny-others` rules. | | `within_resolved_as` | `JSON` | The `within` section resolved to IP and port values. | | `query` | | The search space checked in this step. | | `enforce` | `Boolean` | Is this rule enforced? | | `flow_str` | `String` | A descriptive summary of the 'flow' column. | --- --- sidebar_position: 120 --- # policy_logs Processing summary for each access control rule. Rules not evaluated due to errors can be found here. | Field | Type | Description | |--------------|-------------------|----------------------------------------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the policy test. | | `ok` | `Boolean` | Did the rule pass or fail? | | `skipped` | `Boolean` | Was the rule skipped? | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this test. | | `rule_type` | `String` | The rule type. `ingress-deny`, `egress-deny`, `ingress-deny-others`, or `egress-deny-others`. | | `violations` | `Integer` | Total number of unique violation examples found for this rule. | | `checks` | `Integer` | Total number of checks performed while evaluating this rule. | | `enforce` | `Boolean` | Is this rule enforced? | | `check_log` | `JSON` | A detailed list of checks used to validate the rule. | --- --- sidebar_position: 70 --- # policy_ok Passing access control rules. | Field | Type | Description | |--------------|-------------------|----------------------------------------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the policy test. | | `ok` | `Boolean` | Always true. | | `skipped` | `Boolean` | Always false. | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this test. | | `rule_type` | `String` | The rule type. `ingress-deny`, `egress-deny`, `ingress-deny-others`, or `egress-deny-others`. | | `violations` | `Integer` | Always zero. | | `checks` | `Integer` | Total number of checks performed while evaluating this rule. | | `enforce` | `Boolean` | Is this rule enforced? | --- --- sidebar_position: 100 --- # policy_skipped Invalid access control rules. Invariant could not evalute these rules because some correction is needed. | Field | Type | Description | |--------------|-------------------|----------------------------------------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the policy test. | | `ok` | `Boolean` | Always false for skipped rules. | | `skipped` | `Boolean` | Always true for skipped rules. | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this test. | | `rule_type` | `String` | The rule type. `ingress-deny`, `egress-deny`, `ingress-deny-others`, or `egress-deny-others`. | | `violations` | `Integer` | Always zero. | | `checks` | `Integer` | Always zero. | | `enforce` | `Boolean` | Is this rule enforced? | --- --- sidebar_position: 80 --- # policy_violations Failing access control rules. Excludes rules flagged with enforce = False - see [policy_violations_unenforced](policy_violations_unenforced). | Field | Type | Description | |--------------|-------------------|----------------------------------------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the policy test. | | `ok` | `Boolean` | Always false. | | `skipped` | `Boolean` | Always false. | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this test. | | `rule_type` | `String` | The rule type. `ingress-deny`, `egress-deny`, `ingress-deny-others`, or `egress-deny-others`. | | `violations` | `Integer` | Total number of unique violation examples found for this rule. | | `checks` | `Integer` | Total number of checks performed while evaluating this rule. | | `enforce` | `Boolean` | Always true. | --- --- sidebar_position: 90 --- # policy_violations_unenforced Failing access control rules flagged with enforce = False. | Field | Type | Description | |--------------|-------------------|----------------------------------------------------------------------------------------------------------------------------------| | `index` | `Integer` | Index of the policy test. | | `ok` | `Boolean` | Always false. | | `skipped` | `Boolean` | Always false. | | `policy` | `JSON` | The policy part of the rule definition. | | `rule` | `JSON` | The rule part of the rule definition. | | `errors` | `List of Strings` | List of errors generated from this test. | | `rule_type` | `String` | The rule type. `ingress-deny`, `egress-deny`, `ingress-deny-others`, or `egress-deny-others`. | | `violations` | `Integer` | Total number of unique violation examples found for this rule. | | `checks` | `Integer` | Total number of checks performed while evaluating this rule. | | `enforce` | `Boolean` | Always false. | --- --- sidebar_position: 50 --- # hsrp_properties Information about HSRP Groups within the network. | Field | Type | Description | |---------------------|---------------|----------------------------------------| | `Interface` | `Interface` | Interface. | | `Group_Id` | `Integer` | HSRP Group ID. | | `Virtual_Addresses` | `List of IPs` | Virtual Addresses. | | `Source_Address` | `String` | Source Address used for HSRP messages. | | `Priority` | `Integer` | HSRP router priority. | | `Preempt` | `Boolean` | Whether preemption is allowed. | | `Active` | `Boolean` | Whether the interface is active. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 20 --- # interfaces Interface settings across the network. | Field | Type | Description | |----------------------------------|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------| | `Interface` | `Interface` | Interface. | | `Access_VLAN` | `Integer` | VLAN number when the switchport mode is access (null otherwise). | | `Active` | `Boolean` | Whether the interface is active. | | `Admin_Up` | `Boolean` | Whether the interface is administratively enabled. | | `All_Prefixes` | `List of Strings` | All IPv4 addresses assigned to the interface. | | `Allowed_VLANs` | `String` | Allowed VLAN numbers when the switchport mode is trunk. | | `Auto_State_VLAN` | `Boolean` | For VLAN interfaces, whether the operational status depends on member switchports. | | `Bandwidth` | `Double` | Nominal bandwidth in bits/sec, used for protocol cost calculations. | | `Blacklisted` | `Boolean` | Whether the interface is considered down for maintenance. | | `Channel_Group` | `String` | Name of the aggregated interface (e.g., a port channel) to which this interface belongs. | | `Channel_Group_Members` | `List of Strings` | For aggregated interfaces (e.g., a port channel), names of constituent interfaces. | | `DHCP_Relay_Addresses` | `List of IPs` | IPv4 addresses to which incoming DHCP requests are relayed. | | `Declared_Names` | `List of Strings` | Any aliases explicitly defined for this interface. | | `Description` | `String` | Configured interface description. | | `Encapsulation_VLAN` | `Integer` | Number for VLAN encapsulation. | | `HSRP_Groups` | `List of Strings` | HSRP group identifiers. | | `HSRP_Version` | `String` | HSRP version that will be used. | | `Inactive_Reason` | `String` | Reason why interface is inactive. | | `Incoming_Filter_Name` | `String` | Name of the input IPv4 filter. | | `MLAG_ID` | `Integer` | MLAG identifier of the interface. | | `MTU` | `Integer` | Layer3 MTU of the interface. | | `Native_VLAN` | `Integer` | Native VLAN when switchport mode is trunk. | | `Outgoing_Filter_Name` | `String` | Name of the output IPv4 filter. | | `PBR_Policy_Name` | `String` | Name of policy-based routing (PBR) policy. | | `Primary_Address` | `String` | Primary IPv4 address along with the prefix length. | | `Primary_Network` | `String` | Primary IPv4 subnet, in canonical form. | | `Proxy_ARP` | `Boolean` | Whether proxy ARP is enabled. | | `Rip_Enabled` | `Boolean` | Whether RIP is enabled. | | `Rip_Passive` | `Boolean` | Whether interface is in RIP passive mode. | | `Spanning_Tree_Portfast` | `Boolean` | Whether spanning-tree portfast feature is enabled. | | `Speed` | `Double` | Link speed in bits/sec. | | `Switchport` | `Boolean` | Whether the interface is configured as switchport. | | `Switchport_Mode` | `String` | Switchport mode (ACCESS, DOT1Q_TUNNEL, DYNAMIC_AUTO, DYNAMIC_DESIRABLE, FEX_FABRIC, MONITOR, NONE, TAP, TOOL, TRUNK) for switchport interfaces. | | `Switchport_Trunk_Encapsulation` | `String` | Encapsulation type (DOT1Q, ISL, NEGOTIATE) for switchport trunk interfaces. | | `VRF` | `String` | Name of the VRF to which the interface belongs. | | `VRRP_Groups` | `List of Integer` | All VRRP groups to which the interface belongs. | | `Zone_Name` | `String` | Name of the firewall zone to which the interface belongs. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 70 --- # ip_owners For each node, lists the mapping from IPs to corresponding interfaces and VRFs. | Field | Type | Description | |-------------|-----------|----------------------------------| | `Node` | `Node` | Node hostname. | | `VRF` | `String` | VRF name. | | `Interface` | `String` | Interface name. | | `IP` | `Ip` | IP address. | | `Mask` | `Integer` | Network mask length. | | `Active` | `Boolean` | Whether the interface is active. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 60 --- # mlag_properties Information about each MLAG domain within the network. | Field | Type | Description | |--------------------|-------------|------------------------------------------------------------| | `Node` | `Node` | Node name. | | `MLAG_ID` | `String` | MLAG domain ID. | | `Peer_Address` | `IP` | Peer's IP address. | | `Local_Interface` | `Interface` | Local interface used for MLAG peering. | | `Source_Interface` | `Interface` | Local interface used as source-interface for MLAG peering. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 30 --- # named_structures Structures defined in the configurations, represented in a vendor-independent JSON format. | Field | Type | Description | |------------------------|------------------|-----------------------| | `Node` | `Node` | Node. | | `Structure_Type` | `String` | Structure type. | | `Structure_Name` | `String` | Structure name. | | `Structure_Definition` | `SelfDescribing` | Structure definition. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 10 --- # nodes Global configuration settings for all nodes. Specific configurations for interfaces, protocols, etc are available in other outputs. | Field | Type | Description | |-----------------------------|-------------------|--------------------------------------------------------------------------------------------------------| | `Node` | `Node` | Node. | | `AS_Path_Access_Lists` | `List of Strings` | Names of AS path access lists. | | `Authentication_Key_Chains` | `List of Strings` | Names of authentication keychains. | | `Community_Match_Exprs` | `List of Strings` | Names of expressions for matching a community. | | `Community_Set_Exprs` | `List of Strings` | Names of expressions representing a community-set. | | `Community_Set_Match_Exprs` | `List of Strings` | Names of expressions for matching a ommunity-set. | | `Community_Sets` | `List of Strings` | Names of community-sets. | | `Configuration_Format` | `String` | Configuration format of the node. | | `DNS_Servers` | `List of Strings` | Configured DNS servers. | | `DNS_Source_Interface` | `String` | Source interface to use for communicating with DNS servers. | | `Default_Cross_Zone_Action` | `String` | Default action (PERMIT, DENY) for traffic that traverses firewall zones (null for non-firewall nodes). | | `Default_Inbound_Action` | `String` | Default action (PERMIT, DENY) for traffic destined for this node. | | `Domain_Name` | `String` | Domain name of the node. | | `Hostname` | `String` | Hostname of the node. | | `IKE_Phase1_Keys` | `List of Strings` | Names of IKE Phase 1 keys. | | `IKE_Phase1_Policies` | `List of Strings` | Names of IKE Phase 1 policies. | | `IKE_Phase1_Proposals` | `List of Strings` | Names of IKE Phase 1 proposals. | | `IP6_Access_Lists` | `List of Strings` | (Deprecated) Names of IPv6 filters (ACLs, firewall rule sets). | | `IP_Access_Lists` | `List of Strings` | Names of IPv4 filters (ACLs, firewall rule sets). | | `IPsec_Peer_Configs` | `List of Strings` | Names of IPSec peers. | | `IPsec_Phase2_Policies` | `List of Strings` | Names of IPSec Phase 2 policies. | | `IPsec_Phase2_Proposals` | `List of Strings` | Names of IPSec Phase 2 proposals. | | `Interfaces` | `List of Strings` | Names of interfaces. | | `Logging_Servers` | `List of Strings` | Configured logging servers. | | `Logging_Source_Interface` | `String` | Source interface for communicating with logging servers. | | `NTP_Servers` | `List of Strings` | Configured NTP servers. | | `NTP_Source_Interface` | `String` | Source interface for communicating with NTP servers. | | `PBR_Policies` | `List of Strings` | Names of policy-based routing (PBR) policies. | | `Route6_Filter_Lists` | `List of Strings` | (Deprecated) Names of structures that filter IPv6 routes (e.g., prefix lists). | | `Route_Filter_Lists` | `List of Strings` | Names of structures that filter IPv4 routes (e.g., prefix lists). | | `Routing_Policies` | `List of Strings` | Names of policies that manipulate routes (e.g., route maps). | | `SNMP_Source_Interface` | `String` | Source interface to use for communicating with SNMP servers. | | `SNMP_Trap_Servers` | `List of Strings` | Configured SNMP trap servers. | | `TACACS_Servers` | `List of Strings` | Configured TACACS servers. | | `TACACS_Source_Interface` | `String` | Source interface to use for communicating with TACACS servers. | | `VRFs` | `List of Strings` | Names of VRFs present on the node. | | `Zones` | `List of Strings` | Names of firewall zones on the node. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 90 --- # routes Shows routes for specified RIB, VRF, and nodes. | Field | Type | Description | |----------------------|-----------|-----------------------------| | `Node` | `Node` | Node. | | `VRF` | `String` | VRF name. | | `Network` | `Prefix` | Network for this route. | | `Next_Hop` | `NextHop` | Route's Next Hop. | | `Next_Hop_IP` | `IP` | Route's Next Hop IP. | | `Next_Hop_Interface` | `String` | Route's Next Hop Interface. | | `Protocol` | `String` | Route's Protocol. | | `Metric` | `Long` | Route's Metric. | | `Admin_Distance` | `Integer` | Route's Admin distance. | | `Tag` | `Long` | Tag for this route. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 40 --- # vlan_properties VLAN properties configured on the network. | Field | Type | Description | |--------------|---------------------|-----------------------------------------------------| | `Node` | `Node` | Node. | | `VLAN_ID` | `Integer` | VLAN_ID. | | `Interfaces` | `List of Interface` | Switched interfaces carrying traffic for this VLAN. | | `VXLAN_VNI` | `Integer` | VXLAN VNI with which this VLAN is associated. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 80 --- # vrrp_properties Information about VRRP groups on the network. | Field | Type | Description | |---------------------|---------------|----------------------------------------| | `Interface` | `Interface` | Interface. | | `Group_Id` | `Integer` | VRRP Group ID. | | `Virtual_Addresses` | `List of IPs` | Virtual Addresses. | | `Source_Address` | `String` | Source Address used for VRRP messages. | | `Priority` | `Integer` | VRRP router priority. | | `Preempt` | `Boolean` | Whether preemption is allowed. | | `Active` | `Boolean` | Whether the interface is active. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 30 --- # edges Lists network adjacencies of different types (e.g., Layer 3, BGP, OSPF) in the form of edges. | Field | Type | Description | |--------------------|---------------|-------------------------------------------| | `Interface` | `Interface` | Interface from which the edge originates. | | `IPs` | `List of IPs` | IPs. | | `Remote_Interface` | `Interface` | Interface at which the edge terminates. | | `Remote_IPs` | `List of IPs` | Remote IPs. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 20 --- # layer_1_edges Lists Layer 1 edges after potentially normalizing node and interface names. | Field | Type | Description | |--------------------|-------------|-------------------------------------------| | `Interface` | `Interface` | Interface from which the edge originates. | | `Remote_Interface` | `Interface` | Interface at which the edge terminates. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 10 --- # layer_3_edges All Layer 3 edges in the network. | Field | Type | Description | |--------------------|---------------|-------------------------------------------| | `Interface` | `Interface` | Interface from which the edge originates. | | `IPs` | `List of IPs` | IPs. | | `Remote_Interface` | `Interface` | Interface at which the edge terminates. | | `Remote_IPs` | `List of IPs` | Remote IPs. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 50 --- # bgp_edges All BGP edges in the network. | Field | Type | Description | |--------------------|----------|-----------------------------------------| | `Node` | `Node` | Node from which the edge originates. | | `IP` | `IP` | IP at the side of originator. | | `Interface` | `String` | Interface at which the edge originates. | | `Interface` | `String` | Interface at which the edge originates. | | `AS_Number` | `String` | AS Number at the side of originator. | | `Remote_Node` | `Node` | Node at which the edge terminates. | | `Remote_IP` | `IP` | IP at the side of the responder. | | `Remote_Interface` | `String` | Interface at which the edge terminates. | | `Remote_AS_Number` | `String` | AS Number at the side of responder. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 20 --- # bgp_peer_config Configuration settings for each configured BGP peering on each node in the network. | Field | Type | Description | |--------------------------|-------------------|--------------------------------------------------------------------------------| | `Node` | `Node` | Node. | | `VRF` | `String` | VRF. | | `Local_AS` | `Long` | Local AS number. | | `Local_IP` | `IP` | Local IPv4 address (null for BGP unnumbered peers). | | `Local_Interface` | `String` | Local Interface. | | `Confederation` | `Long` | Confederation AS number. | | `Remote_AS` | `String` | Remote AS numbers with which this peer may establish a session. | | `Remote_IP` | `SelfDescribing` | Remote IP. | | `Description` | `String` | Configured peer description. | | `Route_Reflector_Client` | `Boolean` | Whether this peer is a route reflector client. | | `Cluster_ID` | `IP` | Cluster ID of this peer (null for peers that are not route reflector clients). | | `Peer_Group` | `String` | Name of the BGP peer group to which this peer belongs. | | `Import_Policy` | `List of Strings` | Names of import policies to be applied to routes received by this peer. | | `Export_Policy` | `List of Strings` | Names of export policies to be applied to routes exported by this peer. | | `Send_Community` | `Boolean` | Whether this peer propagates communities. | | `Is_Passive` | `Boolean` | Whether this peer is passive. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 10 --- # bgp_process_config Configuration settings for each BGP process on each node and VRF in the network. | Field | Type | Description | |-------------------------|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------| | `Node` | `Node` | Node. | | `VRF` | `String` | VRF. | | `Router_ID` | `IP` | Router ID. | | `Confederation_ID` | `Long` | Externally visible autonomous system number for the confederation. | | `Confederation_Members` | `String` | Set of autonomous system numbers visible only within this BGP confederation. | | `Multipath_EBGP` | `Boolean` | Whether multipath routing is enabled for EBGP. | | `Multipath_IBGP` | `Boolean` | Whether multipath routing is enabled for IBGP. | | `Multipath_Match_Mode` | `String` | Which AS paths are considered equivalent (EXACT_PATH, FIRST_AS, PATH_LENGTH) when multipath BGP is enabled. | | `Neighbors` | `List of Strings` | All peers configured on this process, identified by peer address (for active and dynamic peers) or peer interface (for BGP unnumbered peers). | | `Route_Reflector` | `Boolean` | Whether any BGP peer in this process is configured as a route reflector client, for ipv4 unicast address family. | | `Tie_Breaker` | `String` | Tie breaking mode (ARRIVAL_ORDER, CLUSTER_LIST_LENGTH, ROUTER_ID). | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 60 --- # bgp_ribs Shows BGP routes for specified VRF and node(s). | Field | Type | Description | |----------------------------------|-------------------|---------------------------------------------| | `Node` | `Node` | Node. | | `VRF` | `String` | VRF name. | | `Network` | `Prefix` | Network for this route. | | `Status` | `List of Strings` | Route's statuses. | | `Next_Hop` | `NextHop` | Route's Next Hop. | | `Next_Hop_IP` | `IP` | Route's Next Hop IP. | | `Next_Hop_Interface` | `String` | Route's Next Hop Interface. | | `Protocol` | `String` | Route's Protocol. | | `AS_Path` | `String` | Route's AS path. | | `Metric` | `Long` | Route's Metric. | | `Local_Pref` | `Long` | Route's Local Preference. | | `Communities` | `List of Strings` | Route's List of communities. | | `Origin_Protocol` | `String` | Route's Origin protocol. | | `Origin_Type` | `String` | Route's Origin type. | | `Originator_Id` | `String` | Route's Originator ID. | | `Received_From_IP` | `IP` | IP of the neighbor who sent this route. | | `Received_Path_Id` | `Integer` | Route's Received Path ID. | | `Cluster_List` | `List of Long` | Route's Cluster List. | | `Tunnel_Encapsulation_Attribute` | `String` | Route's BGP Tunnel Encapsulation Attribute. | | `Weight` | `Integer` | Route's BGP Weight. | | `Tag` | `Long` | Tag for this route. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 30 --- # bgp_session_compatibility Checks the settings of each configured BGP peering and reports any issue with those settings locally or incompatiblity with its remote counterparts. Each row represents one configured BGP peering on a node and contains information about the session it is meant to establish. For dynamic peers, there is one row per compatible remote peer. Statuses that indicate an independently misconfigured peerings include `NO_LOCAL_AS`, `NO_REMOTE_AS`, `NO_LOCAL_IP` (for eBGP single-hop peerings), `LOCAL_IP_UNKNOWN_STATICALLY` (for iBGP or eBGP multi-hop peerings), `NO_REMOTE_IP` (for point-to-point peerings), and `NO_REMOTE_PREFIX` (for dynamic peerings). `INVALID_LOCAL_IP` indicates that the peering's configured local IP does not belong to any active interface on the node; `UNKNOWN_REMOTE` indicates that the configured remote IP is not present in the network. A locally valid point-to-point peering is deemed `HALF_OPEN` if it has no compatible remote peers, `UNIQUE_MATCH` if it has exactly one compatible remote peer, or `MULTIPLE_REMOTES` if it has multiple compatible remote peers. A locally valid dynamic peering is deemed `NO_MATCH_FOUND` if it has no compatible remote peers, or `DYNAMIC_MATCH` if it has at least one compatible remote peer. | Field | Type | Description | |---------------------|-------------------|-------------------------------------------------| | `Node` | `Node` | The node where this session is configured. | | `VRF` | `String` | The VRF in which this session is configured. | | `Local_AS` | `Long` | The local AS of the session. | | `Local_Interface` | `Interface` | Local interface of the session. | | `Local_IP` | `Ip` | The local IP of the session. | | `Remote_AS` | `String` | The remote AS or list of ASes of the session. | | `Remote_Node` | `Node` | Remote node for this session. | | `Remote_Interface` | `Interface` | Remote interface for this session. | | `Remote_IP` | `SelfDescribing` | Remote IP or prefix for this session. | | `Address_Families` | `List of Strings` | Address Families participating in this session. | | `Session_Type` | `String` | The type of this session. | | `Configured_Status` | `String` | Configured status. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 40 --- # bgp_session_status Checks whether configured BGP peerings can be established. Each row represents one configured BGP peering and contains information about the session it is configured to establish. For dynamic peerings, one row is shown per compatible remote peer. Possible statuses for each session are `NOT_COMPATIBLE`, `ESTABLISHED`, and `NOT_ESTABLISHED`. `NOT_COMPATIBLE` sessions are those where one or both peers are misconfigured; the BgpSessionCompatibility question provides further insight into the nature of the configuration error. `NOT_ESTABLISHED` sessions are those that are configured compatibly but will not come up because peers cannot reach each other (e.g., due to being blocked by an ACL). `ESTABLISHED` sessions are those that are compatible and are expected to come up. | Field | Type | Description | |----------------------|-------------------|-------------------------------------------------| | `Node` | `Node` | The node where this session is configured. | | `VRF` | `String` | The VRF in which this session is configured. | | `Local_AS` | `Long` | The local AS of the session. | | `Local_Interface` | `Interface` | Local interface of the session. | | `Local_IP` | `IP` | The local IP of the session. | | `Remote_AS` | `String` | The remote AS or list of ASes of the session. | | `Remote_Node` | `Node` | Remote node for this session. | | `Remote_Interface` | `Interface` | Remote interface for this session. | | `Remote_IP` | `SelfDescribing` | Remote IP or prefix for this session. | | `Address_Families` | `List of Strings` | Address Families participating in this session. | | `Session_Type` | `String` | The type of this session. | | `Established_Status` | `String` | Established status. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 30 --- # ospf_area_config Important properties for all OSPF processes running across the network. | Field | Type | Description | |-------------------------|-------------------|-------------------------------------------------------------------------------------------------------------| | `Node` | `Node` | Node. | | `VRF` | `String` | VRF name. | | `Process_ID` | `String` | Process ID. | | `Areas` | `List of Strings` | All OSPF areas for this process. | | `Reference_Bandwidth` | `Double` | Reference bandwidth in bits/sec used to calculate interface OSPF cost. | | `Router_ID` | `IP` | Router ID of the process. | | `Export_Policy_Sources` | `List of Strings` | Names of policies that determine which routes are exported into OSPF. | | `Area_Border_Router` | `Boolean` | Whether this process is at the area border (with at least one interface in Area 0 and one in another area). | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 20 --- # ospf_interface_config Interface level OSPF configuration details for the interfaces in the network which run OSPF. | Field | Type | Description | |-----------------------|-------------|---------------------------------------------------------------------| | `Interface` | `Interface` | Interface. | | `VRF` | `String` | VRF name. | | `Process_ID` | `String` | Process ID. | | `OSPF_Area_Name` | `Integer` | OSPF area to which the interface belongs. | | `OSPF_Enabled` | `Boolean` | Whether OSPF is enabled. | | `OSPF_Passive` | `Boolean` | Whether interface is in OSPF passive mode. | | `OSPF_Cost` | `Integer` | OSPF cost if explicitly configured. | | `OSPF_Network_Type` | `String` | Type of OSPF network associated with the interface. | | `OSPF_Hello_Interval` | `Integer` | Interval in seconds between sending OSPF hello messages. | | `OSPF_Dead_Interval` | `Integer` | Interval in seconds before a silent OSPF neighbor is declared dead. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 10 --- # ospf_process_config Important properties for all OSPF processes running across the network. | Field | Type | Description | |-------------------------|-------------------|-------------------------------------------------------------------------------------------------------------| | `Node` | `Node` | Node. | | `VRF` | `String` | VRF name. | | `Process_ID` | `String` | Process ID. | | `Areas` | `List of Strings` | All OSPF areas for this process. | | `Reference_Bandwidth` | `Double` | Reference bandwidth in bits/sec used to calculate interface OSPF cost. | | `Router_ID` | `IP` | Router ID of the process. | | `Export_Policy_Sources` | `List of Strings` | Names of policies that determine which routes are exported into OSPF. | | `Area_Border_Router` | `Boolean` | Whether this process is at the area border (with at least one interface in Area 0 and one in another area). | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 40 --- # ospf_session_compatibility OSPF sessions in the network. A session is compatible if the interfaces involved are not shutdown and do run OSPF, are not OSPF passive and are associated with the same OSPF area. | Field | Type | Description | |--------------------|-------------|-----------------------------| | `Interface` | `Interface` | Interface. | | `VRF` | `String` | VRF. | | `IP` | `IP` | Ip. | | `Area` | `Long` | Area. | | `Remote_Interface` | `Interface` | Remote Interface. | | `Remote_VRF` | `String` | Remote VRF. | | `Remote_IP` | `IP` | Remote IP. | | `Remote_Area` | `Long` | Remote Area. | | `Session_Status` | `String` | Status of the OSPF session. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 20 --- # loopback_multipath Flows between loopbacks that are treated differently (i.e., dropped versus forwarded) by different paths in the presence of multipath routing. | Field | Type | Description | |--------------|------------------|----------------------------------------| | `Flow` | `Flow` | The flow. | | `Traces` | `List of Traces` | The traces for this flow. | | `TraceCount` | `Integer` | The total number traces for this flow. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 10 --- # subnet_multipath Flows between subnets that are treated differently (i.e., dropped versus forwarded) by different paths in the network and returns example flows. | Field | Type | Description | |--------------|------------------|----------------------------------------| | `Flow` | `Flow` | The flow. | | `Traces` | `List of Traces` | The traces for this flow. | | `TraceCount` | `Integer` | The total number traces for this flow. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 10 --- # defined_structures Structures defined in the network. | Field | Type | Description | |------------------|-------------|-------------------------------------------------------| | `Structure_Type` | `String` | Vendor-specific type of the structure. | | `Structure_Name` | `String` | Name of the structure. | | `Source_Lines` | `FileLines` | File and line numbers where the structure is defined. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 60 --- # file_parse_status Each file's parse status: pass, fail, or partial. | Field | Type | Description | |---------------|-----------------|-----------------------------------------| | `File_Name` | `String` | The file that was parsed. | | `Status` | `String` | The status of the parsing operation. | | `File_Format` | `String` | The detected format of the file. | | `Nodes` | `List of Nodes` | Names of nodes produced from this file. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 70 --- # ignored_lines Lines parsed but ignored by the model, this can be due to lack of support in the model, syntax errors, or other possibilities. | Field | Type | Description | |------------------|---------------------|---------------------------------------------------------------------| | `Nodes` | `List of Strings` | The nodes that were converted (if applicable). | | `Source_Lines` | `List of FileLines` | The files and lines that caused the issues (if applicable). | | `Type` | `String` | The type of issues identified. | | `Details` | `String` | Details about the issues identified. | | `Line_Text` | `String` | The text of the input files that caused the issues (if applicable). | | `Parser_Context` | `String` | Batfish parser state when issues were encountered (if applicable). | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 80 --- # parse_warnings Warnings such as failure to recognize certain lines and lack of support for certain features. | Field | Type | Description | |------------------|-----------|--------------------------------------------------------------------| | `Filename` | `String` | The file that was parsed. | | `Line` | `Integer` | The line number in the input file that caused the warning. | | `Text` | `String` | The text of the input that caused the warning. | | `Parser_Context` | `String` | The context of the Batfish parser when the warning occurred. | | `Comment` | `String` | An optional comment explaining more information about the warning. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 20 --- # referenced_structures References in configuration files to vendor-specific structures. | Field | Type | Description | |------------------|-------------|-------------------------------------------------------| | `Structure_Type` | `String` | Type of structure referenced. | | `Structure_Name` | `String` | The referenced structure. | | `Context` | `String` | Configuration context in which the reference appears. | | `Source_Lines` | `FileLines` | Lines where reference appears. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 50 --- # unconnected_nodes Nodes that have been created but are not connected to the network. | Field | Description | |------------|-------------------------------| | `Hostname` | Hostname of unconnected node. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 40 --- # undefined_references Finds configurations that have references to named structures (e.g., ACLs) that are not defined. Such occurrences indicate errors and can have serious consequences in some cases. | Field | Type | Description | |---------------|-------------|---------------------------------------------| | `File_Name` | `String` | File containing reference. | | `Struct_Type` | `String` | Type of struct reference is supposed to be. | | `Ref_Name` | `String` | The undefined reference. | | `Context` | `String` | Context of undefined reference. | | `Lines` | `FileLines` | Lines where reference appears. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 30 --- # unused_structures Structures such as ACLs, routemaps, etc. that are defined but not used. | Field | Type | Description | |------------------|-------------|-------------------------------------------------------| | `Structure_Type` | `String` | Vendor-specific type of the structure. | | `Structure_Name` | `String` | Name of the structure. | | `Source_Lines` | `FileLines` | File and line numbers where the structure is defined. | --- :::note Copyright notice Some of these fields are passed through directly from Batfish. The descriptions shown for those fields are taken verbatim from the Batfish documentation. Batfish is licensed under the Apache License, Version 2.0 (the "License"). See https://github.com/batfish/batfish/blob/master/LICENSE. ::: --- --- sidebar_position: 10 --- # errors Errors encountered during Invariant analysis. | Field | | Description | |----------|----------|----------------------------------------------------------------| | `label` | `String` | Stage at which the error was generated. | | `detail` | `JSON` | Error details, including title, detailed message, and error URN. | --- --- sidebar_position: 50 --- # Settings ## Network Each network in Invariant is a series of snapshots of one of your networks. Using networks is how you will organize networks either by environment, location, status, or other factors. ### Adding a new network 1. Navigate to `Settings` in the top nav bar. 2. Scroll to the `Networks` section. 3. Click `Add Network` ![alt text]() 4. Provide a network name and description. 5. Click `Create Network`. ![alt text](img/new_network_dialog.png) ## Notification groups Notification Groups are how you set up email alerts when violations happen in networks. You create a group which contains 1 or more emails that are monitoring one or more networks. Your Notification Groups emails and networks can overlap between groups. ### Adding a new notification group 1. Navigate to `Settings` in the top nav bar. 2. Scroll to the `Notification Groups` section. 3. Click `Add Notification Group` ![alt text]() 4. Fill in the notification group name. ![alt text](img/new_notification_group_dialog.png) 5. Click `Add Email`. 6. Fill in an email address. ![alt text](img/new_notification_group_dialog_email_filled.png) 7. Click `Save` 8. Tick any network box you wish to subscribe the email to. ![alt text](img/new_notification_group_dialog_networks_ticked.png) 9. Provide a description. 10. Click `Create Notification Group` ## Github repositories You can integrate Github with Invariant so that pushes to a snapshot repository are automatically validated by Invariant. This is done via our official Github application. Once you set a repository, you will need to set up a [monitor target](#monitor-targets). ### Adding a Github repository 1. Navigate to `Settings` in the top nav bar. 2. Scroll to the `Github Repositories` section. ![alt text]() 3. Click `Connect a Github Repository...`. This will bring you to Github's website where you may have to authenticate. 4. Click on the account you wish to install Invariant on. ![alt text](img/github_choose_account.png) 5. Find the `Repository access` section and select the repository you wish to monitor. ![alt text](img/github_choose_repo.png) 6. Click `Save` 7. Navigate back to Invariant's `Settings` and check the `Github Repositories` section. It may take a minute for everything to update. ## Monitor targets Monitor targets tell Invariant which repository and path should be monitored and used as the basis for a snapshot. You must have set up a Github Repository prior to using a monitoring target. ### Adding a monitoring target 1. Navigate to `Settings` in the top nav bar. 2. Scroll to the `Monitor Targets` section. 3. Click `Add Monitor Target`. ![alt text](img/nav_monitor_targets.png) 4. Fill in the `Monitor Target Name`. 5. Select a [Github Repository](#github-repositories) from the drop down menu. 6. If the snapshot is not at the root of the repository, provide the path to the snapshot. 7. Select the [Network](#network) that the snapshots will be uploaded to. 8. Provide a description of this monitor target. ![alt text](img/new_monitor_target_dialog.png) ## API token API keys are useful for creating automation via our client or SDK. Your API key will appear once, ensure you copy it to a secure place such as a secret store. ### Adding a new API token 1. Navigate to `Settings` in the top nav bar. 2. Scroll to the `API Tokens` section. ![alt text]() 3. Click `Create API Token` 4. Provide a `Token Name` and `Description` ![alt text](img/new_api_token_dialog.png) 5. Click `Create API Token` 6. Copy the API Token to a secure location such as a secret store. You will not get another chance to copy the token once the box is closed. --- --- sidebar_position: 60 --- # CLI ## Installing the CLI ```bash pip install invariant-client ``` ## Using the CLI The invariant CLI has multiple sub commands that each perform different tasks. Invoking invariant without a subcommand or with the `--help` flag will give you a list of valid sub commands. ```bash (codelab_env) rankeny@Robs-MacBook-Pro codelab_env % invariant --help usage: invariant [-h] [--version] {login,run,show,snapshots} ... Invariant analyzes network snapshots options: -h, --help show this help message and exit --version Display the client and server version. available commands: Run [command] --help for more information. {login,run,show,snapshots} login Authenticate by opening a link in your browser. Saves credentials to ~/.invariant_creds. run Analyze the current directory. show Examine Invariant analysis results. snapshots List prior snapshot analysis results. ``` ### Determining CLI version Using `--version` will show you both the client version and the server version. The client and server versions do not need to match. ```bash $ invariant --version client: 1.4.2 server: v1.5.0 ``` ### Getting debug logs When running any command you can add the `--debug` flag in order to get debug logs. This is helpful information to diagnose and troubleshoot or to provide to Invariant support. ### JSON and TSV output Invariant can produce output in JSON or TSV format. Select them by providing the `--json` or `--tsv` flag. ```bash $ invariant show policy_ok --json [ { "index": 0, "ok": true, "skipped": false, # ... ``` You may want to use these formats in situations such as: - Automation & integrations - Reporting - Database ingestion ## Subcommands ## Login Initiates an interactive login process. Upon succesful login, the CLI gets a time-bound session token. The token will expire after a period of inactivity or 24 hours of use. ### Usage ```bash invariant login [-h] [--debug] ```

Options

| Name | Description | |-----------|-------------| | debug | Enable detailed logging. | ## Run

Usage

```bash invariant run [-h] [--debug] [--json | --fast-json | --condensed] [--target TARGET] [--network NETWORK] ```

Options

| Name | Description | |-----------|-------------| | debug | Enable detailed logging. | | json | Output data as JSON. | | fast-json | Output data as JSON (unformatted). | | condensed | Output only snapshot ID and outcome. | | target | The Invariant project root directory. Default is current directory. | | network | The name of the network being evaluated. | ## Show

Usage

```bash invariant show [-h] [--debug] [--json | --fast-json | --tsv | --condensed] [--snapshot SNAPSHOT_NAME] [file_name] ```

Options

| Name | Description | |-----------|-------------| | debug | Enable detailed logging. | | json | Output data as JSON. | | fast-json | Output data as JSON (unformatted). | | tsv | Output data as TSV. | | condensed | Output only snapshot ID and outcome. | | snapshot | The snapshot to examine. Looks like a UUID, e.g. f17e9368-67fd-4094-b191-4da3f837eb60 . | ## Snapshots

Usage

```bash invariant snapshots [-h] [--debug] [--json | --fast-json | --tsv] [--network NETWORK] ```

Options

| Name | Description | |-----------|------------------------------------------------------------------| | debug | Enable detailed logging. | | json | Output data as JSON. | | fast-json | Output data as JSON (unformatted). | | tsv | Output data as TSV. | | network | Filter snapshots by network. | --- --- id: create-integration-organization-name-api-v-1-integrations-post title: "Create integration" description: "Create integration" sidebar_label: "Create integration" hide_title: true hide_table_of_contents: true api: eJztWktv2zgQ/isET7uAaidBgS50S9N0kW6bBknaS2AItDS22EokS1L2uob++2JISaYfsZ14u31sTrbEmeE8Pg6HHM2pZWND4zt6JoWA1EJGrkFJw63UHAwdRFQq0MxyKS4yGtNUA7NwISyM/dskkXrMBP/qnwQrIUmY4snkOOELMpMoaSyNqIG00tzOaHw3p2+m9jRNwZiXwDRoGt8N6kFEFdOsBAvaOCqUSWO6Ng+NKBc0porZnEZUw5eKa8hobHUFETVpDiWj8ZzamUIBxmouxjSiltsCX7wPJJJLlFjj9CgIjH0psxlyr8pNpbAgLA4xpQqeOv7+JyMFvltMqzT6zqIfOyXmyG4sjemY27waJkyphAtjWVE4OYF6t8hRRxso16WnMoNtpp7heI0OW0yV8Gwby0VASi4y5DZgK5Ww1Cm6hfUG6cipp0M+y+xW9W4cQV1HLYUcfoLULkX1zhu5bsOKXu10g8D6VdRe+xD/6Tx7qlRo6ytm2U5V3NjG0Dx2WlrXOKkGo6QwPqonR8/xJwOTaq681+lN5ZbMqCrIdUOMPn5+dNTA6zHoRJdVAU6pW7ugV2JUGdo5Zk6ZmL0fuSW6HNc66t6IqihoPVgHdfN8PyRu3W8d0Qws48U20leeooW3SB+t3UXLvyv+jb+iFgheQKdsIPIlM3CutdRdsKKVgCJFRqQg16/PXvxx9II8IwaA4OuWp0cdOFb5MFs7RHkAHP/XAGhzWaVFzMWEac6EjQGtNTGrbJ6kOSsKEGPYkNd+dAhEdKF9PKdSQCNse2JHuzelcVYUcgpZUoLNZeZYuYXSPET2kBmeJjjD2gT7JKxlWPL0tLL5Wznm4p3TyflluwKSZ+kG2/wWfX94ms11r5zqZAWaXlXDgqcuRhlH/JdcMCt1gOHZpS8RGgklUwrnj+ehw3buyN/cud57O/X4jj6uA36mNZsF8k89fsm7Br97TrUK+2BW9JA4CzLEcn67zYFUBjQpK2OJ0nLCMyCMKM1LpmcEIwXCNhmOpBoyfGRFbw8gC5gmBUbn0FhfwtRFeV87UlmqAiwQA8XomQE94SkQpwrRMObG+lphHyMmrOAZs5BAidnvQEs+NtLOUdhDwgIENx0tCyJHxOZAnDqEZZkGY8hwRq4uLskQRlIDGTMuuBgT5qoYYqXjYGkqK2H3MVqDAZuowyN3xYyZSp1do8Cri8tvZrLSMgXI0GoridPf8ahGgX3x2tIfavgN2Nb2h68+AdNO8X8tpr6Ab+r7Q22rFJ529rUMNeWCY95Y2DWSOjShtdOyz85MMSNOY+KPHGYvEy3T9mDrUMh2y9KCg7DE5LIqsgBsPsMYMAaTJRMZybhRBZsF8DVQgLOImFQDYA4KjzPhvA/eiX1ZtHPze6qenqqnp+rpe1dPQXm00+E/RSW1vH/uZdPPu9sGJdJOS3/NaiosKHa64BcoPprqYrepP2cREq2edHYa+iuejNz24jyYWPkZxGNvuFySJbdOxIH3nOEV2aZKcXFBvX59+UHgFiQ1/wqZv798/nSB/b+6wL6UlryWlfDhPzn5oa6vmwyyuSXXBb8VcZuDBjJlxlVYclhASabc5mQmK02ajmLvx0FHl1FxB1k6TC37tZDp0ujqXPeVu29liqOlGW+z7J0Zh/G4dyXtk7NRUz9hdF/+5lIsAfkKN8P7bfgYeOjgPBm6e7dmm/Olq3yMYcMCyLmw2EVfJ/NNRxL03tEt/hAV06YL71rmMe3P15rqdZ8p3p8c98PmvWux6knbkK90QWOaW6tM3O8zpXpKy6zXLaGehTR3wGu7/Te4bD2i3kztNYw0mPxMys88DDxT/C+YtW391A+3RzeqPZff+5JmtI7WPyLo5KGGtPkQAJ+HngB9hvnketHnP/+b4VkCeTd3230luYDmWh99MbTcJA/e+yZ4t3bceh5Jp2+3PhsPkm6lRtRUJR7YlobbRECaUw8CDLTxM05Oeke9I3QNRrtkLnE2TtyIjiUAdd6z8Lftq4Jx18J3MZ83wLmj8aavMZjiqMix80+AnkFEc8RdfEfn8yEz8EEXdY2vv1SAlt0NcIFojsh2CMu4Q3lG4xErDKyp2O0S9LfrZhX+Tmi0WfUWXWLm12GFTzSin2G28bOSelBHNAeWuS9S5g3dmZ/y2a1f4K2ctU0K86/nQFQqu5V2ECzNq/c3tzSiw+azk9IjTrMppho29TpL1WVs925OCybGFcMWJfUyEVjtlU1jegP8qP0T7BrLXpnPPYUrDuu6c5KvN+tBXdf/ABn5mh0= sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Create integration --- --- id: create-monitor-targets-organization-name-api-v-1-monitor-targets-post title: "Create Repository Monitor" description: "Create Repository Monitor" sidebar_label: "Create Repository Monitor" hide_title: true hide_table_of_contents: true api: eJztWt9v2zgM/lcEPd0BXtIWA3bw29brgO62rkizvRSBodhMrNWWNElOlgX+3w+UbEf50SRd77Z12FNjm6L4kZ8oSuySWjY1NL6lA1DScCv1gryTAn8YOoqoVKCZ5VJcZjSmqQZmofk+ZHoK1iSJ1FMm+FcnlghWQpIwxZPZaVJ6ycQ2okoaSyNqIK00twsa3y7pm7l9maZgzCtgGjSNb0f1KKKKaVaCBW2cFKqlMd2aikaUCxpTxWxOI6rhc8U1ZDS2uoKImjSHktF4Se1CoQJjNRdTGlHLbYEv3gcayRVqrHF6VATGvpLZAkdv6k2lsCAsfmJKFTx14/ufjBT4bjWt0uhBy8Hgk0dxvzF+flRflo36+0TPG5EabW1Dl1S62DcoCPIHXeDYNkLOf3tGNjEn1yhXR1SAnUt9lxxE5OVaz0atoBx/gtSuReyWNgFt0W8h2zB3w4pR4Jxtng58QGld185lRklhfFTOTp7jnwxMqrnCQNKY3lSOlJOqIINGGHE/PzlF2W+Mv7HMVibwFxcWpqADh914kc5Tbi5jaUwrLWIuZkxzJmwMWkttYlbZPElzVhQgphDoGeLounu+P0JD97eOaAaW8b30+dtL1LjmjGUidYqZWLyfuEW6Pq6OujeiKgpaBwG6bMcj2Tvr4yWVAhpl657bdAbiFjvgsqKQc8iSEmwuMzeUWyjNQ3SPmeFpgjNsTXCAwO5bAPMVanpZ2fytnHLxztnk/LLfAMmzdAe247LHMSY2ugJLr6txwVMXo4zjOii5YFbqgMOLK5+DGw0lUwrnj5ehw7Yo/92d67130I4f6OM6GM+0ZotA/0vPX/Ku4e+RU23SPpgVPSTOgwyxnueGOZDKgCZlZSxRWs54BoQRpXnJ9IJgpEDYJsORVEOGj6zoHUFkAfOkwOg8NtZXMHdRPhZHKktVgAVioJg8M6BnPAXiTCEaptxYX9UcA2LGCp4xCwmUmP0eieRjo+0ClT0kLEBw09GyIHJCbA7EmUNYlmkwhowX5PryioxhIjWQKeOCiylhbhMjVroRLE1lJewxoDUYsIl6fOSumTFzqbMBKry+vPrfICstU4AMUVtJnP1ujGoMOJavrfxjgd+AbbE/fPUJmHeG/2cxNWArlaQy264THo6tUucyg2ORoaVccMwbK1wTqUMILU7L7hxMsSDOYsJS1GmOgmiZto9Gh0r2I0sLDsISk8uqyAKy+QxjwBhMlkxkJONGFWwR0NdAAQ4RMakGwBwUlq7hvA/eiX1ZdHDz+109/a6efldPP7p6Csqjgw5/EpXU+v55FKanu9sGJdJBpL9mNRUWFAdd8AsUH011cRjq0yxCos2TzkGgv+LJyG0vzoOJlXcgvvWGyyVZMnQqDnmiuRaM2v3I6+hu5MIrsl2V4up+sq43vfVB4BYkNf8Kmb+/fP697y+/xXtP5fbycYFdL8fgAq90u2BuRhIlMiIFGbw+f/HXyQvyjBgAgq/bMb1dDLiSlryWlfDhPzv7qa6vmwyClu4JfqtimIMGMmfGVVhyXEBJ5tzmZCErTZqWTe/nYUeXUXEHWTtMrfu1kOna18257it338rU9XDMdG/rxkzDeNy7ko7J2WipnzC6L39zKdaIfI2b4f0YPgYeenSeDN192LLd+dJVPsawcQHkQlhsU26L+QYT2W6aonf8WSqmTbfTt9Zof7nVvKz7TPH+7LS/0Sd1LVI9a3ufrqlHc2uVift9plRPaZn1usXUs5DmjoJtY/UGF7Dn1pu5HcBEg8nPpbzjIQWY4v/Aou2gpv5ze4ij2o/yu2DSfK2j7X5tpw8tpE3PFZ/HXgC9h5llsGqpXnxheKpYtURXdOxan6tXm/3N1Zf17uXq/Xp3MlhIXEyks7hbq40PSbdqI2qqEg9va5/bpECaExCSDbTxbJid9U56J6gfQ14yEQDbx5Q1TnVutPDF9lXBuECNTUfXI7yl8a4OOFMc7TkNPNIyaRTRHGkY39LlcswMfNBFXePrzxUgxtsRLhvNke+ObRl33M9oPGGFgS0ru72D/jFo1uafhEa7rW+ZJhZ+dVb4RCN6B4ud3fx6VEc0B5a5fwRYNnLnfspnQ7/sWz1bWxdmZT8CGarsXtlRsFKv398MaUTHTbe/dCcaqtkc2cfm3mapujzu3i1pwcS0Yti4pF4nUr29yGmgN4sgan8Ee8m6V5ZLL+FKxrrunOSr0HpU1/W/pCq7oA== sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Create Repository Monitor --- --- id: create-network-organization-name-api-v-1-networks-post title: "Create Network" description: "Create Network" sidebar_label: "Create Network" hide_title: true hide_table_of_contents: true api: eJztWVFv2zgM/iuCnu4AL2mLATv4bet1QHdbV7TZXorAUGwm1mpLmiQnywL/9wMl2VWatEnXu20d9tTGoj7xIymKElfUspmh6RU9A7uQ+trQcUKlAs0sl+K0oCnNNTALYTzLpJ4xwb+68UywGrKMKZ7NDzMRIDIljaUJNZA3mtslTa9W9M3CvsxzMOYVMA2aplfjdpxQxTSrwYI2TgrxaEo31qAJ5YKmVDFb0oRq+NxwDQVNrW4goSYvoWY0XVG7VAhgrOZiRhNqua3ww/sIkZwhYovLIxAY+0oWS5x9GzeXwoKwOMSUqnju5g8/GSnw282ySqPNLAeDvzyLu5Xx6yN8XQf4u0SPg0jbJp2MnHyC3K5Z4YoGI3WI4wghdt+F50vbFgE1GCWF8UofHTzHPwWYXHOFPGlKLxvns2lTkYsgjIo/PzhE2W80j7HMNiZizYWFGeiI9qUX6Um7tYylKW20SLmYM82ZsCloLbVJWWPLLC9ZVYGYQYQzwtlt//tuO4/c3zahBVjGq/tE//YSLYaksUzkDpiJ5fupi+H1eW3SfxFNVdE2cs1pNx9jodc+XVEpIICtW+62MZC32EKXVZVcQJHVYEtZuKncQm0egj1hhucZrrCxwI5YdGMRzVeI9LKx5Vs54+Kd08nZ5X4FJC/yLdz221z7qBiwIk3Pm0nFc+ejguM+qLlgVuoohpdnPkUFhJopheunq9hgGyH/3Y3rrbdTjx9o4zaaz7Rmywj/pY9f8i7E755L3Q77aFW0kDiOMsR6nhuVQBoDmtSNsURpOecFEEaU5jXTS4KeAmFDhiO5hgJ/smqwRyALWGQVeuexvj6DhfPyvjxyWasKLBAD1fSZAT3nORCnCtEw48b6Y34fEnNW8YJZyKDG7PdIJh8D2gmCPcQtQPDQ0bIickpsCcSpQ1hRaDCGTJbk/PSMTGAqNZAZ44KLGWHuECNWuhksz2Uj7D6kNRiwmXq8586ZMQupiwsEPD89+98oKy1zgAJZW0mc/m6OCgrsG6+d/GOJX4LtuD989wlY9Ir/Zz41YBuV5bLYrBMezq1Rx7KAfZmhplxwzBs3vKZSxxQ6npZdO5piSZzGhOWIafaiaJm2j2aHIPczyysOwhJTyqYqomDzGcaAMZgsmShIwY2q2DIKXwMVOEbE5BoAc1BctMbrPvgk9mXRzsPvd/X0u3r6XT396OopKo92GvxJVFLr5+denJ7uaRuVSDuZ/prVVFxQ7DTBL1B8hOpiN9WnWYQkt286O4n+ijcjd7w4C2ZWXoP41hcul2TJyEHsskR4Fky688hj9C9y8RPZtkrx5n2ybW9b64PAI0hq/hUK/375/Hu/X36L9Z7K6+XjHLtejsEJPun2zrztSZQoiBTk4vXxi78OXpBnxAAQ/NzNGWyLgDNpyWvZCO/+o6Of6vk6ZBDU9B7ndxCjEjSQBTOuwpKTCmqy4LYkS9loEjoag58nOvqMiifI2mVq3a6VzNdGb691V7n7VuY4WpvZfczemVnsjzt30j45GzX1CyZ35W8uxVogn+NheDeHj5GFHp0nY3Pv1mx7vnSVjzFsUgE5ERa7eJtivrVEQm8JTeIvUCkNHUDXrkvpcLXR0GuHTPHh/HDYNQ1dv1DPu0Zgoyua0tJaZdLhkCk1UFoWg37rDCzkpQu4rst4idvVR9Kbhb2AqQZTHkt5zWOHM8X/gWXXTsz9cHdlo9rP8mdeFkbbZLN52eOhhjQ0IPH3xAugrTCPXNz0F0++MLxD3PQHb4Kv7wNGwc7FVLp1+v0UmJN+ZyXUNDVesNaGu41Lwi0FAwK08R6bHw0OBgeIjx6qmYjU2fDmmrN7xha+2KGqGBcI4/y0Co6+oum2zi1THJU4RDtHXeYSYyS9oqvVhBn4oKu2xc+fG0BGV2MMZM0xAl1EFNxFY0HTKasMbKjXZ3P6x0XYLX8SmmxXu4sGsfT7pcFfNKHXsNzafm7HbUJLYIXrXK+C3LFf8tnIb8QOZ+MwwTzpZ2AUKXuv7DjaRufvL0c0oZPQnq7dHYNqtsCUwBZeZ6n6zOq+rWjFxKxh2EqkHhPDsXtaCdRDoCbdP1F2X7fKauUlXBHXtr2RfF3Yjtu2/RdyJDgU sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Create Network --- --- id: create-notification-group-organization-name-api-v-1-notification-groups-post title: "Create Notification Group" description: "Create Notification Group" sidebar_label: "Create Notification Group" hide_title: true hide_table_of_contents: true api: eJztWt9v2zgM/lcEPd0BXtIWA3bw29brDt3dsqLN9hIEhmIziVZb0iQ5uSzw/36gZDvK73Tdbeuwp9Y2TfIjP1G0mCW1bGJoPKA9afmYp8xyKQwdRlQq0O7qOqMxTTUwC6HQX1qWKkmknjDBP7tbiWAFJAlTPJmdJyIQTiYobRIljaURNZCWmtsFjQdL+mZuX6YpGPMKmAZN48GwGkZUMc0KsKCNk0LVNKZb5mhEuaAxVcxOaUQ1fCq5hozGVpcQUZNOoWA0XlK7UKjAWM3FhEbUcpvjjXeBRtJDjRWaR0Vg7CuZLfDtTb2pFBaExUdMqbyG2f1opMB7K7NKYyAtB4NXHsV+Z7x9VF8Utfp9ope1SBVRKBjPE8v0BKwzw8Ti3diFjVsozLaaKmpuMK3ZglZRKyHKPKcYgcbQFWon/Vp7FVEBdi71fWLKkUk1V54yX9tsz1shd2tWqpUKOfoIqV3L+YDWlGjitxmbfc4Hdi93M/3W84FWFbqgwSgpjE/qxdlz/JNBq5DG9K50nB6XObmthRH+87NzlP1C+hjLbBnGlQsLE9ABLe68SBsmZ8tYGtNSi5iLGdOcCRuD1lKbmJV2mqRTlucgJhDo6ePbVXu9n4d997eKaAaW8fyQ6J9eosIlaywTKayzZpMs+8lx3byPa6X1Pl5SKaBWth65zWAgbrEDLstzOYcsKcBOZeZebbl8qu4RMzxN0MKWgSPsdc8CmK9Q08vSTv+REy7eOp9cXA47IHmW7sB2WvE5xcVaV+DpTTnKeepylHFcBwUXzEodcHjR8yW81lAwpdB+vAwDtkX5bx5cH72jfnzHGFfVZh1dybz0/CVva/6eaGqT9oFVjJC4DCrEep3rT4GUBjQpSmOJ0nLGMyCMKM0LphcEMwXC1hWOpBoyvGR55wQiC5gnOWbnsbnuwdxl+VQcqSxUDhaIgXz8zICe8RSIc4VomHBjfW90CogZy3nGLCRuK3oskg+1NrcrPyQtQHDT0TInckzsFIhzh7As02AMGS3IzXWPjGAsNZAJ44KLCWFuEyNWujdYmspS2FNAazBgE/X4zN0wY+ZSZ7eo8Oa6979BVlqmABmitpI4/907qnbgVL428o8Ffge2wf7w1Sdg3jr+1XJqwJYqSWW23Sc8HFupLmUGpyJDT7ngWDdWuMZShxAanJbdO5hiQZzHhKWuyTsJomXaPhodKjmMLM05CEvMVJZ5FpDNVxgDxmCxZCIjGTcqZ4uAvgZycIiISTUA1qCwfQ3tPngn9m3R0c3vV/f0q3v61T197+4paI+OBvxJdFLr++dJmJ7ubhu0SEeR/pzdVNhQHA3BT9B81N3FcahPswmJNr90jgL9Gb+M3PbiIphYeQ/iS0+4XJElfafiWCTqY8Go2Y+8jvZELjwi29Uprs4nq2ozWu8FbkFS88+Q+fPL59/6/PJLovdUTi8fl9j1dgyu8Ei3TeZmJlEiI1KQ29eXL/44e0GeEQNA8HbzTmcXA3rSkteyFD79Fxc/1PF1XUHQ0wPJb1T0p6CBzJlxHZYc5VCQObdTspClJvXEp/PjsKOtqM2Apf2YWo9rLtO1p4eHLmGNSfFpYSaHkL01kzAfe1fSKTUbPfUGo331m0uxRuQb3Az3Y/gQROjRdTIM93HPdtdL1/kYw0Y5kCthccq5LeaHTCScMhE3ZsLo+G+pmNbDUjfZjGl3uTX7rLpM8e7svLtj1OqmrHrWjE9LndOYTq1VJu52mVIdpWXWaRdUx0I6dTRsZrN3uIg9v97M7S2MNZjppZT3PKQBU/xvWDRD2NQ/bj7kqPZv+Z0wqZ9W0fbIt9WHHtJ6bIvXIy+AEcTqcruayl79y/DLYjVVXVGynZ6ubm2MSAfNk+HeceZKxK3psXRetmu0jhtpV2tETVngR9va46YYkPrLB0kG2ngWzC46Z50zDAimumAiAHOIIWtcakNn4V/bVTnjAjW6hC9r8gxovGtwzhRHf84xYTsYNIzoFCkYD+hyOWIG3uu8qvD2pxIQ52CIS0Zz5LpjWcYd7zMaj1luYMvTdt+gv93W6/J3QqPdCBqGiYVfmSVe0Yjew2LnDwEqTNQUWOZ+Q7Cs5S69yWd9v+QbPVvbFlZk/wYyU9mDssNgld68u+vTiI7qHwoU7muGajbH4sPm3me5GpK7e0uaMzEpGQ4tqdeJFG8OcWroNfmj5p9gH1mPynLpJVy7WFVtkHwHWg2rqvoPiDLRfA== sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Create Notification Group --- --- id: create-security-integration-organization-name-api-v-1-security-integrations-post title: "Create Security Integration" description: "Create a new security integration. This is used to create an OIDC integration." sidebar_label: "Create Security Integration" hide_title: true hide_table_of_contents: true api: eJztWktv2zgQ/isET7uAYidBgS50a90UcLdNg9jtJTAEWhpbbGSSJam4XkP/fTGkpNCOX6mb3aboyZY4HM43Lw45WlLLpobGN3QAaam5XZABWMvF1NBRRDMwqebKciloTHsamAXCiIA5MQ09FxammiFNhwxzbgg3pDSQEStJWk8R5GP/TW+FlkZUKvAP/YzG1NM2cvTvSZNE6ikT/B//JNgMkoQpntydJY0YScDaJEoaSyPaDNL4Zknfze2rNAVjXgPToGl8M6pGEVVMsxlY0MZRIXMa0wcL0ohy1IFiNqcR1fC15BoyGltdQkRNmsOM0XhJ7UIhA2M1F1MaUcttgS8+BhzJJXKscHlkBMa+ltkCZ6/zTaWwICwOMaUKnrr53S8GDbIMllUalWk5GHyagWUZsxtGvHhLZGwsAuVZGkg5xOEqqtWwHY0HgBrWd6CTZr2k1MWuaQNHTj7U5OSTLpBLWnAQNuHZrrk9R0T6WTDDQKrBHjBr4AmrKmoo5fgLpHbFlDd+rEa/GVwo7LoYo8Da/Te9DZ7cAN8rSGvAgGdvW3xcex+iVYVsNRglhfHmPj99gT+rcTwoXRxMyoJc18So0xenZ7VnfI/LGctsGbgYdQEJOrS+J2mh33thqUXMxR3TnAkbg9ZSm5iVNk/SnBUFiClscNL6ebvxh+63wjxmGd/pmW88RYVhbiwTqWPMxOLjxOWF1XlV1L4RZVHQKjBTv5mPbtpKHy+pFFAz2x2SiFtsgMuKQs4hQ3/MZeamcgsz8xjeY2Z4muAKDxY4JDQCmK+R06vS5u/llKNj5zJzennCfPOI6A0kvSrHBU+djTKOcTDjglmpAx9eXPq0X3OYMaVw/XgZKmxvLn1y5XrtPW1OP07HVTCfac0WAf9X3n/Jh9p/D1xq3e2DVVFDohdkiNU8N8wBCxFNZqWxRGl5xzMsX5TmM6YXBC0FwtYZDmuVDB9Z0TnAkQXMkwKtc6ytL2HurHwojlTOVAEWiIFicoJ7FE+BOFGIhik3timw9oO4YwXPmIUEZpj9jkTyueZ2gcweYxYguOloWRA5ITYH4sQhLMs0GEPGC3LVvyRjmEgNZMq44GJKmNvEsMjEGSxNZSnsIaA1GLCJOt5yV8yYudTZNTK86l8+GWSlZQqQIWoriZPfzVG1AIf6a0N/LPAB2Ab746MPDw+NID/MpgZsqZJUZg/rhMdjK1VPZnAoMpSUC4554x7XROoQQoPTslsHUyyIk5iw1B1YDoJombZHo0Mmu5H5mpaYXJZFFjibzzAGjMFkyURGMm5UwRaB+xoowCEiJtUAmIPCAjZc99E7sS+L9m5+v6un39XT7+rp/66egvJor8KfRSW1un8ehOn57rZBibQX6a9ZTYUFxV4V/ALFR11d7If6PIuQaP2ksxfor3gyctuL02Bi5S2I773hckmWDB2LfZqorwWjZj/yPNobufCKbFOleH8/WVXr2vokcAuSmv8Dmb+/fPFf319+j/aey+3lcYZdLcfgAq90W2OuWxIpMiIFuX7be/nX6UtyQgwAwdfNnM4mD7iUlryVpfDmPz//qa6v6wyCku4wfsNimIMGMmfGVVhyXMCMzLnNyUKWmtRdos7P4x1tRsUdZOUwtarXQqYro+trbSt338sUR2dmugvZBzMN7bE1kg7J2SipXzDalr+5FCuOfIWb4XYMnwMNHZ0nQ3Xvl2xzvnSVjzFsXAC5EBY7o0jmzwbY3PRtU9fjjGl3+aALWnWZ4t27s27TWT0J265ty8y3Ul0vkObWKhN3u0ypjtIy67SB0rGQ5s69Gm4DDE7vN+/m9homGkzek/KWh+Zliv8Ni6Yhm/rh5oBGtZ/ld7ikHq2ih+3flh9KSOsWLj6PPQFqBrPG9X2H9uIbwxPDeoe1Xrl1u41N0fvhoNv54GXT0GwDxAXtRDpx2yCsFUjacIyoKWd4KlsZbqKd1Ecb9CLQxnvD3XnntHOKmkGrz5gIkNSN/vaTgKDXuJ67g4T7478PqA1k4ZvtqoJxgeLWLWbvpDc03tSqZ4oj2LPgG4BVTx1FNEdnj2/ocjlmBj7poqrw9dcSUI03Iww5zTFWnDdn3MVNRuMJKwzsUMMf13Vc/0m2YWg8WSx8ZJf4RCN6C4uNHx9UoyqiObDMfbewrOl6fsmToU8ZDZ8H2x5mdD8DI0DZnbSjIB9cfRwMaUTH9ccJM3caoprNMXmxuZdZqnYPcO+WtGBiWjJselLPE724uQSqoddBFjV/gn1oVSvLpadw5WZVtUryFWw1qqrqXzWVHYE= sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Create a new security integration. This is used to create an OIDC integration. --- --- id: create-token-organization-name-api-v-1-tokens-post title: "Generate API Token" description: "Generate a long-lived, revokable refresh token (API token)." sidebar_label: "Generate API Token" hide_title: true hide_table_of_contents: true api: eJztWc1u2zgQfhWCpy2g2ElQoAvd0my6SLdNjSTtJQgEWhpbbCSSJSm7rqB3XwwpKXQcx0682zZFT7Ykcma++SenppZNDY2v6NHolFzKGxCGXkc0A5NqriyXgsb0bxCgmQXCSCHFdK/gM8giomEmb9i4AKJhosHkxCIB8gfScn9fDGhEpcLNXIrTjMY01cAsOE5JIvWUCf7NfU0EKyFJmOLJ7CBx202ipLE0ogbSSnO7oPFVTd/O7VGagjGvgWnQNL66bq4jqphmJVjQxq1CajSmKxxoRDliUszmNKIavlRcQ0ZjqyuIqElzKBmNa2oXCgkYq7mY0ohabgt88SGgSM6QYoPskRAY+1pmC9x9l24qhQVh8RNTquCp2z/8bFDBdcBWadSX5WDwyaOoKROLDxOHa1msJurfiKooKErSCeplQ9Zl2bF+ApnjdnvTRN0aOf4MqV3S3hVtldtxCyncmvzca4k2DZLTYJQUxkM93N/Hn2XPu6icpSdVQc7bxfQRylxnw44W8aJ5tyUrliXkSHHy6aANDDKSvegv9w+QwRPNaiyzlQkk5MLCFHQg4oVf0ivd8TKWxrTSIuZixjRnwsagtdQmZpXNkzRnRQFiCgGdS9zd9M/rdXLpfhuMfct48dDSv/yKBkPJWCbSJ/voabcf/bSXPq6pFNASW9bcXWUgbnEPXFYUcg5ZUoLNZea2cguleQztMTM8TZDDCoMNseC+BTBfI6Wjyubv5JSL904mp5eHBZA8S+/B1iWFdeZpk9IWIra0AklH1bjgqbNRxjESSy6YlTrw4cWZT60thZIphfzjOlTYist/d+V67W2U4wfquAn2M63ZIqB/5P2XvG/9d0tWd90+4IoaEsdBhljOtJc5kMqAJmVlLFFazniGBV9pXjK9IGgpELbNcCTVkOEjKwZbOLKAeVKgdXa19RnMnZW3xZHKUhVggRgoJnsG9IynQJwoRMOUG+tbk21AzFjBM2YhgRKz345IPrXUTpDYY8wCBIuOlgWRE2JzIE4cwrJMgzFkvCCj0zMyhonUQKaMCy6mhLkySqx0O1iaykrYbUBrMGATtbvlRsyYudTZORIcnZ79b5CVlilAhqitJE5+t0e1Amzrr936XYFfgO2wPz76BMx7wf8zmxqwlUpSma32CY/HVqljmcG2yFBSLjjmjVtcE6lDCB1Oy24cTLEgTmLCUqRptoJombY7o0MiDyNLCw7CEpPLqsgCZ/MZxoAxmCyZyEjGjSrYInBfAwU4RMSkGgBzUNg0h3wfXYl9W7Sx+P3unn53T7+7px/dPQXt0UaFP4tOarl+boXp+VbboEXaiPTX7KbChmKjCn6B5qPtLjZDfZ5NSHT3pLMR6K94MnLlxWnQ30U/9YbLJVl/gbhRE+21YNTVI0+jv5ELr8ju6xT7G1In+7K2PgosQVLzb+DK+8v9l9/7/vIp2nsut5e7GXa5HYMTvNINrruXLYkrMiIFOX9z/OrP/VdkjxgAgq+7PYP7POBMWvJGVsKb//Dwp7q+bjMISvqA8TsSlzloIHNmXIclxwWUZM5tThay0qSdxAx+Hu/oMypWkKXD1LJeC5kufb3La127+06m+LU004eQvTfT0B5rI2mbnI2SeobRuvzNpVhy5BEWw/UYPgUa2jlPhureLNn9+dJ1Psa4+eaJsDh9xGX+bIADRD+adHPEmA7rlUljM2SKD2cHQz/LdGNMPevmk5UuaExza5WJh0Om1EBpmQ36yBhYSHPnT93w8wKj0TvK27k99yPXYylveGhPpvg/sOimnKn/3J3IaDuo9SUtab820epMtaeHEtJ2LorPY78AVYFp4vx27HnyleER4XZseetb/Qgy8GUuJtLx6cOlRU76wImoqUo8Py197uKStIcQtDdo4+02OxzsD/aRPtqnZCIQpx9j97Puu8k1yIg7Dr1b7Vn4aoeqYFygSM7mdesyVzS+bzjNFEdAB0ijH8fn6GvxFa3rMTPwURdNg6+/VIC6ubpGj9ccpXK+lXHnthmNJ6ww8ADIP87bsHpB1gnd+ZVY+MCq8IlG9AYW987Xm+smojmwzI3m63bdsWe5d+kjtqOzUnUwofod6I/KPrj2OgjH0YeLSxrRcTt/L91hhGo2x9zB5l5mqfoU7N7VtGBiWjGcOVJPEx27u4NpobcuH3V/gjKwrJW69iucbzVNryTfQDbXTdP8C5UenXY= sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Generate a long-lived, revokable refresh token (API token). --- --- id: create-user-organization-name-api-v-1-members-post title: "Create or invite user" description: "Create or invite a user in the organization. Creating a user creates a 'managed user', a whole user account managed by this organization. An invited user is not managed by this organization. You can disallow outside user invitations in the security settings." sidebar_label: "Create or invite user" hide_title: true hide_table_of_contents: true api: eJztWutv2zYQ/1cIftkGKM6jabrpW5p1QLY1DfIoMASGQEsnm6tEsiRlzzP0vw9HUrYUP5OsXdvlUyLpeLzfvUnfjFo2NDS+o7cGNHnLBBtCCcLSfkQzMKnmynIpaEzPNDALRGrCxZhbIIxUuIYLYkf4fsgE/5shdY84Yi6GDVHqFhvCyHel2yNz77+LCCOTkSzAk7E0lZWwpKEZTIkdcXOP+akIImRBAkOE3LboD1mRlAmSccOKQk6IrKzhGTQgxtw6StMAMpBWmtspMWARiunRiEoF2pGdZzSmHhVqLknauyWClZAkTPFkfJiUUA5Am0RJY2lEG740vpvRXyf2NE3BmNfANGga3/XrfkQV06wEC9o4KmRHY7q0BY0oR9MoZkc0oho+VlxDRmOrK4ioSUdQMhrPqJ0qZGCs5mJII2q5LfDFuxZHcoEca9weGYGxr2U2xdX3+aZSWHSReEaZUgVP3fr9Pw36yay1LRPTd7lDoDRqznIwC3FmyMhYGtNguZZgN0hRRxRKxotNCN44gjqizqiQJSXYkcxMd3tuoXSvpICdJBoww9OEVU6vXaHqqBFGDv6E1HYUf+e/9ReLXiOn08qOfpdDLt466WgdbRNA8ixdoY+OC1QVz1bpJpe6ZMjEEayx9i1+q9GBLAz14xieL9YGfrsoZxWKFXK0dPju/OezjvowOXFMTiUXzEqNQgd9Ti98sIStSqYUgohnbZvG/7n9vYG3yvHsBpvcoG5txLRmUxdY4YWoisJ5SrP81GcI8jZkiBpzscgSX0tagAdSFsBEC+E1iIycezqsizmrCkvjnBUG6ohWBhIDtlJJKrPNnG4NkGskJWdIuoIZN4mpFGisSxtZnRtyPSdcYrSbCXx+bSnJV3nfB2RY2a58LdghZfFGP49N4o8U2dulI2vr6xV8DI6iwSgpjBf+6OAA/3RbnOvK1eK8KshVIKafoty5hmCFohrvWTDqamyTdzt3emhyCtZ28swRP9rSD9zc222xbcdo/qXvI8G1aGSpWSHkVHHy/pB4AIZcYofljX3s7buz7bqAjWW2akH3aaljs2tPMsf8OKs1lg/P60Pkxv2tMcztlmj62VO4pG4sE+mjpTtv1m8zbdBX1MSoZzAXtlsO4Y3WUrcCrBuESJERKcjVL2evfjx4RfaIASD4ulnTo87G99dlZJGs6PHB4ed2gCY8Ki1iLsZMcyZsDIjWxNhLJOmIFQWI4aos+aW7QEQX0j+gk0bcYgXcFf36N9Ol+/PaevOEk9ZO5c7xakl6WQ0Knj63wJ9Dx8v95YZucret7rt9uz/FSDlrZYhufrsZhbuKsjKWKC3HeHvBiNK8ZHpK0FIgbMhweOOS4SMrejs4soBJUqB1nmrrC5g4K++KI5WlKsDidUuR7xnQY54CcaIQDUNurD8M7AJizAqeMQuJbxGfiOR94Oaa04eYBQgWHS0LInN3k+TEISzLNBiD11OX5xdkALnUQIaMC3dP5jpPYqVbEe7BdgGtwYBN1NMtd8mMmUidXSHDy/OLTwZZaZkCZIjaSuLkd2tUEGBXf23onwr8GmyD/eHRJ2AyF/xfs2nrLPl0bJXCo8GuyFBSLjjmjQWuXOo2hAanZR8cTOHuSCtFWOpuUHeCaJm2T0aHTDYjSwsOwhIzklWRtZzNZxgDxmCyZCLDi2FVsGnLfQ0U4BARk2oAzEHts1N73wdXYt8WbS1+z93Tc/f03D39191Tqz3aqvCvopPq1s+dMH291bbVIm1F+m12U7R7Of3NNx+hu9gO9etsQqL7J52tQL/Fk5ErL06DiZUfQDz2hsslWXLjWDzxnrN9RbaqU1zcdS9fX94KLEFS878h8/eXx88X2P+rC+wLackvshLB/D89m/9/Zf4zKfKCp/7Hi6OjL+rHi1A/UNANtm9Y3IxAA5kw4/prOSigJBNuR2QqK03CcFHvy3GOeT3F/qFzlO7qtZBp5+v9vdYddn6XKX4tzXATsrdm2LbH2kDapWKjpH7DaF315lJ0/PgSW6H1GN63NPTkKtlW93bJVldL1/cawwYFkDfC4kAdkvmTIc7E+Wk7NxoX0/3Z0vBcvc8U3x8f7of5PDeap8fNzF2lCxrTkbXKxPv7TKme0jLrzUOjZyEdOYdqBvquMRy9p/w6sVeQazCjMyk/8LZBmeK/wbSZ3Ev95+ZATrVf5TuaJHyto+U5wTk/lJCGWT98HngC1AXmiavFKN+bvxieEHFtaBsX3rV0n3Q3w9hZMWdEX+Tsx5f5yfHey1eHr/aOX54c7Q1e5OneUfrTyYv85ITl7GTVIM+OK71GW2M5bpxlecYmvO5Oy8xnaEQunY4WowbeamQe9RE1VYlH/87nJqmQcH5GZwVtvNONj3oHvQM0BzpXyVwSDoZbmo6dT+W03LaV0Z/HaXt0nkUs/GX3VcG4QOW6yJuFyL2j8aqxV6Y4muYQs1wI335ERxjz8R2dzQbMwK0u6hpff6wAzXzXx8yjOaYMF+Io+6DAnBWcaa2xvr8K6e0Hsk7qJrzF1Ce4Cp9oRD/AdOXobt2vIzoClrmp31mgO/Nb7t34zNnwWar+GJx+BaYFZTfS9ltp8fLd9Q2N6CCM9pYulqhmE8zhbOJllmpeCt27GS2YGFYMf/mnnifml+YmNEAPmSdq/mmV465WZjNP4c5cdT1Xkj/G1f26rv8Bj8wp0w== sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Create or invite a user in the organization. Creating a user creates a 'managed user', a whole user account managed by this organization. An invited user is not managed by this organization. You can disallow outside user invitations in the security settings. --- --- id: delete-monitor-target-organization-name-api-v-1-monitor-targets-monitor-target-uuid-delete title: "Delete Repository Monitors" description: "Delete a repository monitor." sidebar_label: "Delete Repository Monitors" hide_title: true hide_table_of_contents: true api: eJztWUtv2zgQ/isET7uAaidBgS50a9MUSLdJgzTtJQgEWhpbbCSSJUf2uob++2IoypH8iJ1mt22KnmxJw+F88yZnwVFMHI+v+SUY7SRqO2dnWtEfx28inoFLrTQoteIxfw0FIDDB7B112VAPeMS1ASuI9DTjMc88cWB2JewEMEm0nQglv3qqRIkSkkQYmUwPk8AnQU/pkpUXSVXJLEkapjziDtLKSpzz+HrB387wZZqCc69AWLA8vr6pbyJuhBUlIFjnqWg7HvMNfHnEJeEzAnMecQtfKmkh4zHaCiLu0hxKweMFx7khFg6tVBMe8bG2pUAe88AFJRZEEFCzBjb7SF/rOlrKsKaGb5ag3fF9hyM7J441qcCCM1o5cLT26OA5/fRt+qHymhtXBbsMxLyO+PODQ6JNtUJQSH+FMYVM/QbDz47WLjpyGUvWR9ns5FBg5TrySoUwAdsR+ENDUkeBxO/lvC6tiqWaCiuFwhis1dbFosI8SXNRFKAm0OFzRavr5fN2DV3535p8GoUs7iN93VDUZBSHQqWesVDz92PvSf11ZNfwRlVFwUnvLafTdn0d8Tvp4wXXCgKzvuZWlUG41Qa4oij0DLKkBMx15pdKhNI9hPdIOJkmtMPaBkuzcD36DCn2fPK6+daB+Yo4vawwf6cnUp15mbxe7hdAyyzdgK0Jku3mCe69h4iBV0fSi2pUyNTbKJMUB6VUArXt+PD8vAnSwKEUxtD+8aKrsDWX/+7KbbS3U44fqOO6s15YK+Yd/i8b/2VnwX/33GrV7Tu7kobUcSdD9PPcVQ6scmBZWTlkxuqpzKiUGStLYeeMLAUKQ4ZjqYWMHkUx2MORFcySgqzzWFufw8xbeV8cqS6Nr8kOivEzB3YqU2BeFGZhIh02FXkfEFNRyEwgJFBS9nskkk+B2wkxe4hZgFHRsbpgeswwB+bFYSLLLDjHRnN2cXrORjDWFthESCXVhAlfxBhqv0Kkqa4U7gPaggNMzOMtdyGcm2mbXRLDi9Pz/w2ysToFyAg1aubl92tMEGBff23pHwv8A2CL/eHRp2C2FPw/s6kDrEyS6my9T3g4tsoc6wz2RUaSSiUpb9zhGmvbhdDiRHHrYao58xIzkRJPtxdEFBYfjY6Y3I8sLSQoZC7XVZF1nK3JMA6co2QpVMYy6Uwh5h33dVCAR8RcagEoB3U27+374ErctEU7i9/v7ul39/S7e/rR3VOnPdqp8CfRSfXr516Ynm617bRIO5H+mt1Ut6HYqYJfoPkI3cVuqE+zCYlWTzo7gf6KJyNfXrwGE9S3oL71hssnWXblWezSRLgWjNp61PBY3sh1r8g2dYp395N1vaqtj4pKkLbyK2TN/eXz731/+S3aeyq3l48zbL8dgxO60l0ac9WSRJExrdjlm+MXfx28YM+YA2D0ul0z2OQB5xrZG12pxvxHRz/V9XXIICTpPcZvWVzlYIHNhPMdlh4VULKZxJzNdWUZKR4cDn4e71hmVKogvcNUX6+FTntfV/fa1u6+0yl9Ld3kPmRnbtK1x9ZI2idnk6TNhtG2/C216jnyBRXD7Rg+dTT06DzZVfduyTbnS9/5OCdGBbAThTRLI7LmbLCc3/GomUnFfLhYm1rVQ2HkcHo4XBneDRcbhmy1n9rZaTuOq2zBY54jGhcPh8KYgbE6GyxDZ4CQ5t7h2lnfBwrXxpPezvASxhZcfqz1rewaXBj5N8zbgVrafG6PbNw2q5qal4SvdbQ+QlzyIwl5GMHR86ghqH0EjbWnXEZEkJ0tYyPirirpiNT73IYeC+cMMilY15hmejQ4GByQUEY7LIVPVUH8MIHdNK1dsXAn+e2a2wagCP/g0BRCKtrbm2cRjH/N400jS2EkSX5IodL3AB7xeNOg9SbiuaYcd80Xi5Fw8NEWdU2vv1RASrq+Ie+2ktzSu0kmvYtmPB6LwsE9KP+4DCH0J9sGqnURNW+CqKInHvFbmG+ZDFMC/I4irGu5vqkjnoPI/Fx7EejIVw12OKyVNwqcZSy/Pnl3cnVCFgu3L0GK4MtR+6dTAPoCLhYNhe/z6nopb9M61jd1Xf8LvqRAMg== sidebar_class_name: "delete api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Delete a repository monitor. --- --- id: delete-network-organization-name-api-v-1-networks-network-uuid-delete title: "Delete Network" description: "Delete Network" sidebar_label: "Delete Network" hide_title: true hide_table_of_contents: true api: eJztWV9v2zgM/yqCnu4AL2mLATv4bes6oLutK/pnL0FgKDYTa7UlTZKTywJ/9wNl2ZOTtEmXu20d9pTYokj+SIqkxRW1bGZoPKIXYBdS3xk6jqhUoJnlUpxnNKYZFGDBryeJ1DMm+Be3nghWQpIwxZP5cSI8i6T9l1QVz5KkYUAjaiCtNLdLGo9W9O3CvkxTMOYVMA2axqNxPY6oYpqVYEEbR4UCaExDhjSiXNCYKmZzGlENnyuuIaOx1RVE1KQ5lIzGK2qXCvcaq7mY0YhOpS6ZpTH1XCy3BRJ4aOQWX9d11EndgPrNoltRHwKO5AI51ghag1FSGDC49+ToOf5kYFLNFVLSmF5XzlbTqiBXnpjWEX1+dIy0qRQWhMW/TKmCp07A8JPBvatAL6XRt5Y3koxltjKBvlxYmIEOFL5uSOrIkzhZxhlRi5iLOdOcCRuD1lKbmFU2T9KcFQWIGQR8bnB33T3fb6Eb91tHNAPLePEQ6euGokanGMtE6hgzsfwwdbHT34d+9W9EVRQU7d5yOm/31xH9qn28olKAZ9a33LoxELfYApcVhVxAlpRgc5m5rdxCaR7De8IMTxOUsCGgcwuVk0+Q2l5Mjpq1AOYr5PSysvk7OePivdPJ2eVhBSTP0i3YmkNyv3t8eO+houcVaHpZTQqeOh9lHM9ByQWzUgcxvLxoDqnnUDKlUH68Cg22EfLf3biN9Xbq8QNtXAf7mdZsGfB/2cQvee/jd09R62EfSEULidMgQ/Tz3E0OpDKgSVkZS5SWc54BYURpXjK9JOgpENZnOJJqyPCRFYM9AlnAIinQO4f6+gIWzsv74khlqbAGEgPF9JkBPecpEKcK0TDjxjb1dh8Qc1bwjFlIoMTsdyCSj57bGTJ7jFuAYNHRsiBySmwOxKlDWJZpMIZMluTy/IJMYCo1kBnjgosZYa6IESvdDpamshJ2H9AaDNhEHe65S2bMQursChlenl/8b5CVlilAhqitJE5/t0d5BfaN15b+UODXYFvsjz99Ahad4v+ZTw3YSiWpzDb7hMdjq9SpzGBfZKgpFxzzxldcU6lDCC1Oy+4cTLEkTmPCUuRp9oJombYHo0MmDyNLCw7CEpPLqsiCYGsyjAFjMFkykZGMG1WwZRC+BgpwiIhJNQDmoEB4T+6jK3HTFu0sfr+7p9/d0+/u6Ud3T0F7tNPgT6KT6tfPvTA93WobtEg7kf6a3VTYUOw0wS/QfPjuYjfUp9mEROtfOjuB/opfRq68OAsmVt6B+NYbLpdkyY1jscsS/lowautRw6O7kQuvyLZ1il/vJ+t63Vq3AkuQ1PwLZM395fPvfX/5LdZ7KreXhzm2347BGV7pds5c9yRSZEQKcvXm9MVfRy/IM2IACL5u9wy2RcCFtOSNrETj/pOTn+r62mcQ1PQB57csbnLQQBbMuA5LTgooyYLbnCxlpQkaHowd/DzR0WVUrCC9j6m+XQuZ9lbXZd3X7r6TKa6WZvYQsvdmFvrj3pO0T85GTRuB0X35m0vRC+RLLIb3Y/gYWOjgPBmae7dm2/Ol63yMYZMCyJmwOD3bJHvtJmzED7LQJM0HVDu8o1EzsorpcLUx1KqHTPHh/HjYzu+Gq3DcVrvBnZ63E7lKFzSmubXKxMMhU2qgtMwG3VkaWEhzF4HtuO8az28TWm8X9gqmGkx+KuUdDyOAKf43LNsJW9ost99wVDe7miKY+NU62pwidvxQQ+pncvg8aQhqd6Sm0lF2R8TrTrrDElFTlfjN1FtuzyLxHx7oY9CmccL8ZHA0OEKllDS2ZC53efU3HNTzX6ezhX/sUBWMC2TjLL3ynhvReNs4kimOShyjpdoJbkTj3rx0HNFcYsYa0dVqwgzc6qKu8fXnChDhaIyxqjkGmfNxxl3AZTSessLAhrpdwqZ/XPkD8Seh0XYYrX/FsjkSFT7RiN7Bcn2yi3nsO8reNGg9riOaA8vcQHrl6TDClA04bFQpDPfuzL0+e3d2c4bO8ZcoXgsfgVH7J8jjfQVXq4bCtWt13enbdID1uK7rfwEaVQcZ sidebar_class_name: "delete api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Delete Network --- --- id: delete-notification-group-organization-name-api-v-1-notification-groups-notification-group-uuid-delete title: "Delete Notification Group" description: "Delete Notification Group" sidebar_label: "Delete Notification Group" hide_title: true hide_table_of_contents: true api: eJztWd9v2zgM/lcEPd0BXtIWA3bw29Z1h+62rmi7vRSFodhMrNWWNIlOLgv8vw+Uf0xpkiZd7rZ12FNim6K+j6QoSlxwFBPH42t+plGOZSpQauX4TcS1AeufTjMe8wwKQAiF/ra6Mkmi7UQo+dm/SpQoIUmEkcn0MFGBcDIhaZeseZlUlcySpJmAR9xBWlmJcx5fL/jrGT5PU3DuBQgLlsfXN/VNxI2wogQE67wUTctjvkE3j7hUPOZGYM4jbuFTJS1kPEZbQcRdmkMpeLzgODekxqGVasIjPta2FMhj3mpBiQUJhFZg3gzsPUnUddRjWTHLN6PoZn0XaGRnpLEmU1hwRisHjsYeHTylnwxcaqUhSR7zy8pbcFwV7KIV5nXEnx4ckmyqFYJC+iuMKVpaw4+Oxi4CXMZSRKBsZnIosHIBXqkQJmADwJeNSB21In4u5+1pVSzVVFgpFMZgrbYuFhXmSZqLogA1gUDPFY2u++fNFrryv3XEM0Ahi/tEXzYSNTnFoVCpVyzU/N3YR9TyOPJr+0ZVRcHJ7p2m0258HfGv6OMF1wpaZcuWu2sM4q3W0BVFoWeQJSVgrjM/VCKU7iG6R8LJNKEZVibo3cL16COkuBST1823gOYL0vS8wvyNnkj11mPydrkfgJZZuoZbs0g2u6cN7x0gtroCpOfVqJCp91EmaR2UUgnUNojh+VmzSFsNpTCG5o8XocFWQv67G7ex3lYcP9DGdTBeWCvmgf7nTfyyt2387jjV3bAPZiULqeMgQyznuascWOXAsrJyyIzVU5kBE8xYWQo7Z+QpUNgl7tRCRo+iGOwQyApmSUHe2dfXZzDzXt6VR6pLQzsjc1CMnziwU5kC81CYhYl02OzSu5CYikJmAiGBkrLfnkw+tNpOSNlD3AKMNh2rC6bHDHNgHg4TWWbBOTaas/PTMzaCsbbAJkIqqSZM+E2MofYjRJrqSuEupC04wMTs77lz4dxM2+yCFJ6fnv1vlI3VKUBGrFEzj9+PMS2AXeO1k9+X+CVgx/3hq0/BrAf+n/nUAVYmSXW2Wic8nFtljnUGuzIjpFJJyhtfeY21DSl0PFHceppqzjxiJlJfXu9EEYXFvdmRkvuZpYUEhczluiqyINiaDOPAOUqWQmUsk84UYh6Er4MCPCPmUgtAOSiYfGneB+/ETVm0dfP7XT39rp5+V08/unoKyqOtBn8UldTy/rkTp8e72wYl0lamv2Y1FRYUW03wCxQfbXWxnerjLEKiuyedrUR/xZOR3168BRPUt6C+9YbLJ1l25VVss0R7LRh1+1Gjo7+RC6/I1lWKX+8n6/qutd4r2oK0lZ8ha+4vn37v+8tvsd5jub3cz7HL5Ric0JVu78y7niSJjGnFLl4dP/vr4Bl7whwAo9fdmMG6CDjTyF7pSjXuPzr6qa6v2wxCSO9xfqfiKgcLbCacr7D0qICSzSTmbK4ry8jw4HDw80RHn1F9dyg8TC3btdDp0te7c20qd9/olL6WbnIfs7duEvpj40raJWcT0mbCaFP+llotBfI5bYabOXwILLR3ngzNvR3Z+nzpKx/nxKgAdqKQemqrYi99342t9rTIOs1Zquv+8ajpXsV8uFjpb9VDYeRwejhc0/YbLja05mrf77PTrpFX2YLHPEc0Lh4OhTEDY3U26BfbACHNfYh2XcJLWuBN7L2e4QWMLbj8WOtbGYaIMPIfmHctuLT53B3yuG1GNbtk0n6to9XmY6+PEPK2aUfPo0ag9mturL1kv4Za7KxfTRF3VUmHqqXP3WJl7cmEggCsa7w0PRocDA4IlNEOS+GTWwv/Pg8u+bqHj/AvDk0hpCKN3uiL1rXXPF7XuhRGEp5DMtqqf3nE403N15uI55py3jVfLEbCwXtb1DW9/lQBmeD6hqLdSgpTHwSZ9CGb8XgsCgcrJPqUz/+4aJfUn4xH68l1AaDmzaKq6IlH/Bbm93SMKSl+RxirFq9v6ojnIDLf8160chSNBgMNK1seLY1+1b48eXNydULea29kWhRttEbdn2BTWAa4WDQSvvar6x5vU07WN3VdfwFATT3m sidebar_class_name: "delete api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Delete Notification Group --- --- id: delete-security-integration-organization-name-api-v-1-security-integrations-integration-uuid-delete title: "Delete security integration" description: "Delete security integration" sidebar_label: "Delete security integration" hide_title: true hide_table_of_contents: true api: eJztWVFv2zgM/iuCnu4AL2mLATv4bes6oLutK9puL0FgKDYTa7UlTZKTywL/9wNl2ZWTtEmXu20d9pTYokh+JEXS4opaNjM0HtFrSCvN7ZJcg7VczAwdR1Qq0MxyKc4zGtMMCrDQEp4LC7NmNUmknjHBvzZPgpWQJEzxZH6cGE+e8Dt6k4RPSVXxLEka7jSi7Q4aj1b07cK+TFMw5hUwDZrGo3E9jqhimpVgQRtHhRJpTNeZ0ohyQWOqmM1pRDV8qbiGjMZWVxBRk+ZQMhqvqF0q3G+s5mJGIzqVumSWxtRzsdwWSBBgJh9xqa6jTvqGDb5ZfCvuQ8CRXCDHGsFrMEoKAwb3nhw9x58MTKq5Qkoa0+vK2WxaFeTKE9M6os+PjpE2lcKCsPiXKVXw1AkYfja4dxXopTQGgOWNJGOZrUygrzM36EDh64akjjyJk2WcIbWIuZgzzZmwMWgttYlZZfMkzVlRgJhBwOcGd9fd8/0WunG/dUQzsIwXD5G+bihqdIqxTKSOMRPLD1MXQ/196Ff/RlRFQdHud1Hg99cRvdM+XlEpwDPrW27dGIhbbIHLikIuIEtKsLnM3FZuoTSP4T1hhqcJStgQ0LmFyslnSG0vJkfNWgDzFXJ6Wdn8nZxx8d7p5OzysAKSZ+kWbM0hud89Prz3UNHzCjS9rCYFT52PMo7noOSCWamDGF5eNIfUcyiZUig/XoUG2wj5727cxno79fiBNq6D/Uxrtgz4v2zil7z38bunqPWwD6SihcRpkCH6ee4mB1IZ0KSsjCVKyznPgDCiNC+ZXhL0FAjrMxxJNWT4yIrBHoEsYJEU6J1DfX0BC+flfXGkslRYC4mBYvrMgJ7zFIhThWiYcWObErQPiDkreMYsJFBi9jsQySfP7QyZPcYtQLDoaFkQOSU2B+LUISzLNBhDJktyeX5BJjCVGsiMccHFjDBXxIiVbgdLU1kJuw9oDQZsog733CUzZiF1doUML88v/jfISssUIEPUVhKnv9ujvAL7xmtLfyjwa7At9sefPgGLTvH/zKcGbKWSVGabfcLjsVXqVGawLzLUlAuOeeMO11TqEEKL07JbB1MsidOYsNR1vHtBtEzbg9Ehk4eRpQUHYYnJZVVkQbA1GcaAMZgsmchIxo0q2DIIXwMFOETEpBoAc1AgvCf30ZW4aYt2Fr/f3dPv7ul39/Sju6egPdpp8CfRSfXr516Ynm61DVqknUh/zW4qbCh2muAXaD58d7Eb6tNsQqL1L52dQH/FLyNXXpwFEytvQXzrDZdLsuTGsdhlCX8tGLX1qOHR3ciFV2TbOsW7+8m6XrfWR4ElSGr+FbLm/vL5976//BbrPZXby8Mc22/H4AyvdDtnrnsSKTIiBbl6c/rir6MX5BkxAARft3sG2yLgQlryRlaicf/JyU91fe0zCGr6gPNbFjc5aCALZlyHJScFlGTBbU6WstIEDQ/GDn6e6OgyKlaQ3sdU366FTHur67Lua3ffyRRXSzN7CNl7Mwv9ce9J2idno6aNwOi+/M2l6AXyJRbD+zF8Cix0cJ4Mzb1bs+350nU+xrBJAeRMWJyibZK9Bt8T+4lfMDZD+zRfU+24j0bN/Cqmw9XGhKseMsWH8+Nhy+tZOOUbrtYHcrUb7+l5O7erdEFjmlurTDwcMqUGSsts0J20gYU0d/HZCrjG090E3tuFvYKpBpOfSnnLw/hgiv8Ny3b+ljbL7Rce1c2upkQmfrWONmeNHT/UkPqJHT5PGoLaHbipdJTdAfK6k+4oRdRUJX5R9Zbbk0r8ZwlGAGjTuGh+MjgaHKFSShpbMpfZvPoPu6/n6g6AhX/sUBWMC+TpzL7yfh3ReNvkkimOGh0HA9mec2lE44156ziiucRsN6Kr1YQZ+KiLusbXXypA/KMxxrnmGKAuAjLugjWj8ZQVBjb075I9/ePKH6Y/CY2242q9L5bNcarwiUb0FpbbpsOYB7+j/E0r1+M6ojmwzA22V54OY1DZgMNGlcMD0R3T12fvzm7O0GP+EsZr4WM0av8EdaCv4GrVULh2r647fZsOsh7Xdf0vGEczpg== sidebar_class_name: "delete api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Delete security integration --- --- id: delete-token-organization-name-api-v-1-token-token-uuid-delete title: "Revoke API token" description: "Revoke an API token and immediately invalidate all access tokens associated with it." sidebar_label: "Revoke API token" hide_title: true hide_table_of_contents: true api: eJztWV9v2zgM/yqCnu4AL2mLATv4res6oLutK9puL0VhKDYTa5UlTZKTywJ/94GSnNpJ06Tr7U+HPSW2KZI/kiIpcUEdm1iaXtHDsxNyqW5AWnqd0AJsbrh2XEma0nOYqhsgTBKkckhFmCwIryooOHMg5oTLKRO8YA4IE4KwPAdrA60lzFqVI2FBZtyVhLsBTajSYBiKOCloSgsQ4MCrkGXKTJjkX/zXTLIKsoxpnk33MxcIwk9d8yLLwkqaUAt5bbib0/RqQd/M3KFX4iUwA4amV9fNdUI1M6wCB8Z6KuRNU3rLjiaUI2bNXEkTauBzzQ0UNHWmhoTavISK0XRB3VzjSusMlxOa0LEyFXM0pZGL404ggUdEPuDLpkmWEtcQfrPgVtD7DkdyihwbBGzAaiUtWFx7sPccf/ruvai9nca1IOeRmDYJfb63j7S5kg6kw79Ma8FzL2D4yeLaRUcvbdChjgdJ1jFX246+XDqYgOkofBFImiSSeFnWm9DIFAPKcCZdCsYoY1NWuzLLSyYEyAl0LYyrm+XzZgtd+t8Gw9sxLu4jfRUoGnSKdUzmnjGT8/djHzf9dejX+EbWQlC0e8vppF3fJPRW+3RBlYTIrG+5VWMgbnkHXCaEmkGRVeBKVfil3EFlH8J7xCzPM5SwJmDpFqpGnyB3vZi8Ct86MF8ip8PalW/VhMt3Xidvl/sVULzI78AWNslm98Tw3kHFyKuj6Vk9Ejz3Pio47oOKS+aU6cTw/DSmhcChYlqj/HTRNdhayP9w4wbrbdXjJ9q46axnxrB5h/9hiF/yLsbvjqJWw74jFS0kjzoZop/nLksgtQVDqto6oo2a8gIII9rwipk5QU+BdDHDkdxAgY9MDHYIZAmzTKB3HuvrU5h5L++KI1eVxvpHLIjxMwtmynMgXhViYMKtC0V2FxBtCc+gwuz3SCQfI7djZPYQtwDBomOUIGpMXAnEq0NYURhsKkZzcnZySkYwVgbIhHHJ5eS24/ArWJ6rWrpdQBuw4DL9eM+dMWtnyhTnyPDs5PS7QdZG5QAFonaKeP39Gh0V2DVeW/rHAr8A12J/+O6TMFsq/r/51IKrdZarYr1PeDi2Wh+pAnZFhppyyTFv3OIaK9OF0OJ07MbDlHPiNSYsR552J4iOGfdodMjkfmS54CAdsaWqRdEJtpBhLFiLyRKPAwW3WrB5J3wtCPCIiM0NAOagjvCe3AdX4tAWbS1+f7qnP93Tn+7pZ3dPnfZoq8GfRCfVr587YXq61bbTIm1F+nt2U92GYqsJfoPmI3YX26E+zSYkWT3pbAX6O56MfHnxFgzXqd96w+WTbLg83mqJeC2YtPUo8FjeyHWvyO7qFG/vJ5tm1VofJJYgZfgXKML95fMffX/5LdZ7KreXj3Nsvx2DY7zSXTpz1ZNIURAlyfnroxf/7L0gz4gFIPi6XTO4KwJOlSOvVS2D+w8Ofqnr65hBUNN7nN+yuCzBAJkx6zssNRJQhdHJXNWGoOHB+iHKLxIdy4yKFaR3mOrbVai893VV1qZ2963K8WtlJ/che2cnXX9s3Em75GzUNAhMNuVvrmQvkM+wGG7G8LFjoUfnya65t2t2d770nY+1bCSAHEuHkzMkC2eD5UiOJmEmldLhYm1q1QyZ5sPp/tBXkOHidpDW+IGcmbaTttoImtLSOW3T4ZBpPdBGFYPlPhk4yEsfXe0Y7wL3ZgibNzN3DmMDtjxS6oZ3vcs0/xfm7fQsD5/b8xk1YVWcF8avTbI+HVzyQw1pnLfh8ygQNH67jJWnXIZ/1J0sN0JCbV3heaj3ud1nJB4q0H9gbPDD9GCwN9hDpbSyrmI+L0X14+R1OXZdTZWd/Pa9prTRLA7+c0MtGJeoqXfmIsbFFU3vmmYyzRHnPvKIuqedOet1QkuFue6KLhYjZuGDEU2Drz/XgPa7usYoNxzD00dQwX2oFjQdM2HhHlP8dR630t9kE4I2euQ8bKYan2hCb2Denwdj/vuBktct2Vw3CS2BFX6IvYh0GL3adTisVTfcSsut/Or47fHlMXolXr5ELWJ0J+2fTv7vK7hYBArf5jVN31KoY9N8BcQtORU= sidebar_class_name: "delete api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Revoke an API token and immediately invalidate all access tokens associated with it. --- --- id: get-report-organization-name-api-v-1-reports-report-id-get title: "Get data file" description: "Fetches a data file as Apache Arrow (feather). Use the 'Get report details' endpoint for a listing of constituent data files." sidebar_label: "Get data file" hide_title: true hide_table_of_contents: true api: eJztWf9v0zoQ/1cs/wJIod0mJJ7y2xgDjQdj2ga/TFPkOtfGLLGNfWlfqfK/P52TZsm6rR19Dxjipzbx+e4+980X34KjmHgeX/DXAgXblxK855cRT8FLpywqo3nM3wDKDDwTLCWyscqBCc/2rZAZsH3nzIw9HYPADNyzAfvkgWEG7MlbQObAGocsBRQq908Y6NQapZGNjWOC5cqj0hNmxkwa7VFhCRqv5fgBj7ix4ATpcpTymE8ATwPTJDFuIrT6FtYSLQpIEmFVMt1NarE+af4kKk2SCSCPuAdZOoVzHl8s+LsZ1qBfgXDgeHxxWV1G3AonCkBwPlARZx7zlhWPuCK7WIEZj7iDr6VykPIYXQkR9zKDQvB4wXFuaaNHp/SER3xsXCGQx7wsAxdUmBNBjYcdpbyqolbeCrrvlruU87HDkR0Tx4rgOvDWaA+e9u7t7NBPPwLOymClcZmz04aYR1wajaCRyIW1uZKB8fCLpz2La32qqqoi/mJnl95uuolbR35HVavlUWDpO+CURpiA66A7q0mqqCEJsnwwt9Ox0lPhlNAYg3PG+ViUmCUyE3kOegIdPue0u2qf7zbnefitKF0ouu8jfV1TVORBj0LLwFjo+cdxCLH+PgqC5o0u85yTk5acjpb7q4hfax8vuNHQMOtb7qYxCLe+Ba7IczODNCkAM5OGrQqh8A/hPRJeyYQkrAho3cLN6AtI7AXwRb3WgfmKOO2XmL03E6U/BJ2CXe5XwKhU3oKtzqi73dPkwgYqNrw6mp6Uo1zJ4KNUUdIUSgs0rhPD8+M6oxsOhbCW5MeLrsFWQv6HG7e23lo9fqKNq85+4ZyYd/jv1/HLPjTxu6Gom2HfkUoW0gedCtEviucZsNKDY0XpkVlnpioFJph1qhBuzshToLGpcEw6SOlR5IMNAlnDLMnJO9v6+hhmwcub4pCmsDkgMA/5+LkHN1USWFCFOZgoj/VZvAmIqchVKhASKKj6bYnkc8PtkJg9xC1AvQU6k1ObQZ1JUIeJNHXgPRvN2cnRMRvB2DhgE6E0dSQinHgMTdghpDSlxk1AO/CAid3ecyfC+5lx6SkxPDk6/t8gW2ckQEqo0bCgf9hjGwU2jdcl/bbAzwCX2B+efRpmreL/mU89YGkTadLVPuHh2Ep7YFLYFBlpqrSiunGNi5rnDoQlThRXAaaes6AxE5J4+o0gonC4NTpicj8ymSvq8H1myjztBFtdYTx4T8VS6JSlyttczDvh6yGHgIh56QCoBnWE9+Q++CSu26K1h9+f7ulP9/Sne/rZ3VOnPVpr8EfRSfXPz40wPd7TttMirUX6e3ZT3YZirQl+g+aj6S7WQ32cTUh080tnLdDf8csoHC/BggmaK9Dfe8MViiw7DyzWWaK5FoyW51HNo72R616R3dYptpeZQfe+tT5pOoKMU98gHO8vdl786PvL77HeY7m93M6x/XYMDulKt3Mz3fckUaTMaHb65uDlXzsv2XPmARi9Xu4Z3BYBxwbZG1Pq2v17e7/U9XVTQUjTe5y/ZHGegQM2Ez50WGaUQ8FmCjM2N6VjZHjwOPh1oqOtqHSC9D6m+nbNjeyt3pR1V7v73khaLfzkPmQf/KTrjzszaZOaTZrWAqO76rcyuhfIJ3QY3o3hc8dCW9fJrrnXa3Z7vQydj/dilAM71EhDNiKrvw3qyR2P6ulVzIeLlflWNRRWDae7w2Z6N1y0I7cqTO7cdDmSK13OY54hWh8Ph8LagXUmHbRZMkCQWYit5bzvjDKzDpp3MzyFsQOfHRhzpbq+FVb9DfPloE3Wy9H1BDDsqo+3pFmtotUxYsuPNOTNaI6eRzVBFZJlbAJlG/yN7qxNg4j7sqCvod7yMstY80lB3gPnay9M9wY7gx1SyhqPhQhVqVGf5rHtZPVmleyUtp8+8G2Mh/APDm0ulCY8weWLJnwueHzbeFRYRdbYDdEfYohHPL4e3F5GPDNUEC/4YjESHj65vKro9dcSyMwXl5QKTlEMh0BLVYjnlMdjkXu4x2hPT5t8e8bugrAMMj2vM66kJx7xK5j35stUI3+g4FVLVpdVxDMQaZiJLxo6inGLHQ4rJyAlXJvubw/PySXN7UyjQpMA0fJP54Doa7dY1BShD6yqVtm6tawuq6r6F2yCYAo= sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Fetches a data file as Apache Arrow (feather). Use the 'Get report details' endpoint for a listing of constituent data files. --- --- id: get-report-summary-organization-name-api-v-1-reports-report-id-summary-get title: "Get report details" description: "Returns a summary of the report. Includes a listing of all data files and their row counts." sidebar_label: "Get report details" hide_title: true hide_table_of_contents: true api: eJztW11vG7cS/SsEn26BjeQEAXqxb6njBG5rx5CdvBjGgt4dSawpcktypajC/vdiSO6Kq2/ZaVoHfrJlcYZzzgyHwyG9oJaNDE1v6XtmGXmX52AMvUtoASbXvLRcSZrSAdhKS0MYMdVkwvScqCGxYyAaSqVtj5zLXFQF4AjBjeVyhCOYEKRAvUMu8DtZoBDXRKsZyVUlrenRhKoSNMOZzgua0hHYgdN67afKMqVHTPK/3JBMsglkGSt5Nn2d+elNFn7JeJFlwcJsBJYm1EBeaW7nNL1d0F9n1iP8BZgGTdPbu/ouoSXTbAIWtHGjcAaa0lYlTShHEkpmxzShGv6suIaCplZXkFCTj2HCaLqgdl6ioLGayxFN6FDpCbM0pVXltFhuBTg2UTM5L2hdJ+18aygfPW8zz6dII7lEjTXC1WBKJQ0YlH1zcoI/uu6+rhxLw0qQQRhME5oraUFaHM7KUvDcKe7/YVBmEdlTavSo5X4Gz+P63x0pR7D2GT/WSZenY5V0KGk0SrAzpR+OVnbp5Vo9IRodQXL+aeiiqQvaLQQ3oCg4GsHEVWfAUnC3FRg4XdVMiKxVzy1MzH4sddIMYFqzeYTtnRDkg9NWJ3SqRIUxepx5YYSshKAYd43qL15bvZxc3f8Bue3E+G2EJ5JFk85lAV9pfbdBPh7mLDdKVEjzC7dHcbtjhuuWUaTX59oXco8K3IjMwB9SaZmtXsL00Ux6+uqEgtZKvxD5WCLPPH017veTkmnIrHrZ0V52tGfO7WE7Wp1sCWNfcu8yYG3yU7d8uFHS1/t4ENpgx9PnXG7D7S7SZsEYpmSlGatwuHrfWNMNC25MBQeEwlLtuZfAxFuMjhM9cwJYOKvKn76OOEMFESzfVXHcvJdOAC3+akFLJrK2bj/Y9CBJrpwkYqgEZEMuCy5HxyGpBJAPjaDLu1JCbm/UMVpOvZBVe1dKcHHjryX7DZNrvKyCi02MAuzq02kcW9E3g3AwqhM6AcvcSlg7DxowJj7SfYvkce11Lk9oSuxMTLt0DVDWJeBK55BVWj5W07XTQD5ruUyX2UQVIL4peJ85yQUqDgzs2GC8jy4a92AcamAWiozZnYFYMAuvLHf9ijYavSh5Zx1jIfN8W9cGpduRxUEfVst672Dl9L88xEeh2qFiLaxXz0FbyqBgHZcWRqDpDk9sPBRsHRzq3j34QxNmw1YR4fm40nlrez91jfrfnrxGSx7ZBlqD0jCxqYb3Q9xcxkWDlimXU6Y5kzb1e1vKKjvO8jETAuQojr4blK7bz9sbZDfuZ43dTsu42DX0vR9RY0/OWCbzR+eR80Yel1hrfbqgSsLGCnuVDMQtN8BlQqgZFNkE7FgV3cLuUN33zPA8wxnWJtgTYe67COYvqOldZce/qxGXF86mDQXHqgGKF/kGbL5Hut09obt5gIlBV7xvVfeC585HBcc26IRLZpWOYnh+6Xu0QcOElSXOny5iwtZC/ruT69nba8e/yHFd7zxEYPySixC/B061GvbRrMiQPI0yRLfNfTMGUhnQZFIZS0qtprwAwkipubvjQE+BtCHDkVxDgR+Z6B0QyBJmmUDvPNXXlzBzXj4UBx7bBVggBsTwlQE95TkQZwrRMOLG+suWQ0BMmeC4v2cwwez3RCRfgrYzVHaMW4DgpqOVaK6dnDmEFYUGY8j9nFydX5J7GCoNZMS4xPsn5u4wiFVOguXuvukQ0BoM2Kx8uueumDEzpYsBKrw6v/zHIJda5QBYnCNcZ7+TKYMBh8ZrM/6pwK/BNtiPX30SZq3h38ynBmxVZrkq1uuE47FV5akq4FBkaCmXHPPGEtdQ6RhCg9OyBwdTzomzmLDcdSYOgmiZtk9Gh0p2I8sFB2mJGatKFFGw+QwTTnHurrfgphRsHoWvAQEOETG5BsAcFHdM4nmP3ol9WbR383upnl6qp5fq6d+unqLyaC/hz6KS6u6fB2F6vrttVCLtRfpjVlNxQbGXgh+g+AjVxX6oz7MISVZPOnuB/ognI7e9OAYzqx7g0f1tl2TJjVOxj4n2wirsR15H25GLW2SbKsW4RbnK1meJW5DS/C9w2/vbk7ffu3/5GPaeS/fyaY7tlmPgXh1Ebw27nsQRBVGSDD6c/vz/k5/JK2IACP65keltioBLZckHVUnv/jdv/lPt65BB0NIdzm9U3IxBA5kx4yosdS9gQmbcjslcVZog8WBs778THW1GbZ4qtIepLq9C5TteIGwvd39XubtONKNdyC7MKPbH1pV0SM5GS/2Eybb8zZXsBPIV89dDWzB8iRh6cp6M6d5v2eZ86SofY9i9AHImLT6brv2dLZ6Q3NNsmvj3yCntL9ZeLNd9VvL+9HU/XKL1F+0j6rof3TyBnjaPrSstaErH1pYm7fdZWfZKrYpeu1p6FvKxi7HmJfc1rlAfPL/O7ACGGsz4VKkHHvuYlfw3mDdPqHP/dbJ82+2k/DaXhW/rZP2BeKsPLaTh0TV+vvcDardohv6qvl0EwXbSLofohjD6ulltJBwt0IugjffG9E3vpHeCRpXK2Alz2SmY/xFseHlPvP/NasqM8tw//Hg/8GPhq+2XgnF3p+28ugiRckvTTW/bWckR8OvOnWsav7pvOLtL6FhhFryli8U9M/BZi7rGP/9ZAXJ6e4fxrzkGrouqgrsgLmg6ZMLADnL+NwiL7CeyDUwTUXLul1mFn2hCH2De+TcBTIzfceJ1Tt0DsjGwwv1rwyKMw4AubaRhbdvD1dWu8Y9nN+ic0JIJJoRoT5pfol2ha91i4Ue44q+uW2N9PYmvneq/ARBJccQ= sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Returns a summary of the report. Includes a listing of all data files and their row counts. --- --- id: get-report-summary-text-summary-organization-name-api-v-1-reports-report-id-summary-text-get title: "Get report detail (json or text)" description: "Returns a user-facing textual or JSON summarizing the report. This is what users see when calling 'invariant show' in the CLI." sidebar_label: "Get report detail (json or text)" hide_title: true hide_table_of_contents: true api: eJztGu9v27byXyH4pR2g2mlRYA/61mbZXvLaNEi87UMQCLR0tthSpEZSdl1D//twJKVQsWO7yV67Fv2UWLo73u878W5NLZsbml7TX5hl5FWegzH0JqEFmFzz2nIlaUovwTZaGsJIY0A/m7Gcyzmx8NE2TBClydnVu3Nimqpimn9y70ogGmql7YhMSm4IN2RZMusIGGIAyLIESXImBMI/4XLBNGfSElOq5RPCpaNx/OZ0RBOqatAMmTktaErnYC8d7St34moCH7t/s0zpOZP8k4POJKsgy1jNs8XzzPNjsvBPxossMwENZcnmYGlCDeSN5nZF0+s1PVtar5TXwDRoml7ftDcJrZlmFVjQxkHhMTSlPV2aUI56q5ktaUI1/NVwDQVNrW4goSYvoWI0XVO7qhHRWM3lnCZ0pnTFLE1p0zgqllsBzgBImZwWtG2T/rwNUR98bnfOu4giOUeKLYqLhMDY16pYIfZdurmSFqTFV6yuBc8d/vi9QedZR8fWGg1pORj8VakCdjHzFt+jK85YI1ApaCTaJtRqlnsSAXWqlAAmI9yJB4mwZ0wYaB2zRgnIDFjL5dyRYXL1buYsOeQwV0LpzKyMhWoIN+QZbRKeyEYIijrrODlGGuTK02gTKlXmyO5k/1wRh4cIS17YMoLm0sIcdAT9p4NoE1oCn5d2J+x/PUibUG6y9029srCblVNDzgKYR7KgKy6Z2Ic16eA8GrKiWW75AvZhnkagbUIFzFm+ypZcFmq52+xvHCj5M4C26CweVk3fQ24HQXE9tG9kmk7pvUYH2hpqYUO4DYYHzuCc79LH0zuXX72Xxun2WFV1Y6EgXPqEgNHIpqqxLidiCn1iiFA5E6TjY7TFCbeJP8woUeYMPNG2RTQNplbS+DB4cXSEf4ZMXjUuL84aQS4DMH1wKnCRvSMVTELkd3QeEohniLvPIxwjNzvVFGT1enp59NwnigeJbSyzjdkZr1cepGfbnWVcidAy7atmClorbVLW2DLLSyYEyDnEGkTstv+9Q9Xub4s+aRkXu0B/8RAY39JYJnN4qG1OO3xM0D336ZoqCVsz811loNxyi7hMCLWEIqvAlqpwqNxCZT6H9pQZnmd4wsYB+7wJ30VivkZKrxpbvlFzLt86npxedjOgeJFvkc13AfebJ9TvA1gMtCJOL5qp4LmzUcEx7DHJWF+1ArOrc9+FBAoVq2s8P13HCtuM9C+tXK+9vXx8RR23ET7Tmq0i+q+8/5K3wX8PPOqu20enoobkcZQhhml9EgoMqRpjSa3VghdAGKk1x/RH0FIgbchwJNdQ4M+uAO1WsoRlJtA6j7X1OSydlQ+VI1dVLcACMSBmzwzoBc+BOFaIhjk31n9eHCLEggleMAsZVJj9HinJH4HaCRL7HLMAwaKjlSBq5toCxw5hRaHBGDJdkYvTczKFmdJA5oxL/MxirmYTqxwGy3PVSHuI0BoM2Kx+vOUumDFLpYtLJHhxev5/E7nWKgco3MeoIo5/h1MHBg711w7+sYJfge1k//zok7DsGf/HbGrANnWW+6+sx8rW1MeqgEMlQ0655Jg3buWaKR2L0Mlp2QcnplwRxzHBPltJc5CIlmn7aOmQyG7JcsHBX100ooiczWcYA8a4Fl4WpOCmFmwVua8BAU4iYnINgDko/mKIz/3sSuzbor3F70f39KN7+tE9fe3uKWqP9ir8m+ikhvXzIJm+3WobtUh7Jf0+u6m4odirgu+g+QjdxX5Rv80mJLn7pbNX0O/xy8iVF6fBzKoP8ODbR5dkycSR2KeJcC2YdPXI0+hv5OIrsm2dYnxFeVdbv0ssQUrzT+DK+8ujl1/6/vIh2vtWbi8fZ9hhOwYneKUb3a0PLYkQBVGSXP56/PN/jn4mz9xUFR93OKNtHnCuLPlVNdKb/8WLf9X1dcggyOkO43ckJiVoIEtmXIelpgIqsuS2JCvVaBKGlqN/j3f0GdVNfeKPqaFehcoHb++edV+7+0bl+LYy851jVTOP7XFvJB2Ss5FTf2ByX/7mSg4c+QKL4f0y/BFp6NF5Mlb3fs6250vX+RjDpgLIibS4GIBg/tvALyPQxE/cUzpeb8zk2zGr+XjxfBzWD8brfk2gHYf1g7EbO2EDpRfdTkGjBU1paW1t0vGY1fWo1qoY9SEzspCXztG6hYUrDFPvQWdLewkzDaY8VuoDjw3Nav4/WHWbArl/ndyuMDgsX+uy8LZNNvcgenrIIQ27Bfh76gHaMK27vF0dOPnI8NuB9qN/GsTu5vluRL99Qj+cxN966+003a8ihGH50e0s/Gg46fZggzF2/2gwovZP786e8WnrksJMOSX0Qd6tr/ThntBg3cHrLpuQ8OmEXgraeG9bvBgdjY5Q37UytmIu+wbL/AY2bNQQ79/kKeoXt29QjT/dLRBRVv/6+zvBV/DEcS0Ylyij8/B1CJ1rmm5bZ2E1Rw09d5Hv4ocmNI0XbTolJ/3stlRYHa7pej1lBn7Xom3x8V8NoC2ubzAvaI4B7QKt4C64i97/7lXj08uQfH4i98nUBZlc+fTT4C+a0A+wGiwIYcH4ggdvqra9cfsirHBLTesAd+yPfDbxCbWjs9EUIPseA7NCbXfC3kTZ8reTCU3oNCwShTSg2RLty5aeZVX3BdI9W1PB5LxhOBH2GwAuUXc3ZN0yiM87SfdPVKSHSlmvPYTrxdu215Fv73Frov0bRBOcBg== sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Returns a user-facing textual or JSON summarizing the report. This is what users see when calling 'invariant show' in the CLI. --- --- id: get-report-text-summary-organization-name-api-v-1-reports-report-id-text-get title: "Get data file (json or text)" description: "Returns a user-facing textual or JSON summary of a report file." sidebar_label: "Get data file (json or text)" hide_title: true hide_table_of_contents: true api: eJztGu9v27byXyH45W2AGqdFgT3oW5tlW7I2DZxs+xAEAi2dbbY0qZGnuJ6h//3hSEqhEsd2k71uLfopsXR3vN931N2ao5g5nl/xHwUK9qoswTl+nfEKXGlljdJonvMxYGO1Y4I1DuyzqSilnjGEj9gIxYxlpxfvzphrFgthV8xMmWAWamORTaWCA55xU4MVRO2k4jmfAY79+0v4iBcBrSiMnQkt//JghRYLKApRy+LmeRGIuSL+U8iqKOj0YgbIM+6gbKzEFc+v1vx0iUGM1yAsWJ5fXbfXGa+FFQtAsM5DEXme854ez7gkSWuBc55xC3820kLFc7QNZNyVc1gInq85rmpCdGilnvGMT41dCOQ5bxpPBSUq8Crz8p9UvG2z/rx7Ij763O6cdwlFdkYUWxKXCIHD16ZaEfZduqXRCBrplahrJUuPP3rvyNzr5NjakuVQgqNfC1PBNmbe0ntynqloFCmFjMTbjKMVZSARUSfGKBA6wb0MIAn2VCgHrWfWGQWFA0SpZ56M0Kt3U2/JIYelUcYWbuUQFkO4Ic9kk/hEN0px0lnHyRHRYBeBRptxbQpPdiv7Z4Z5PEJYygrnCbTUCDOwCfQfHqLN+BzkbI5bYX8JIG3GpSveN/UKYTsrJ46dRrCAhGAXUgu1C+uygwtoxIoVJcob2IV5koC2GVcwE+WqWEpdmeV2s7/xoOyPCNqSswRYM3kPJQ6C4mpo38Q0ndJ7jQ60NdTCPeHuMTxwBu984xBP73xGDF6aJsgjs6gbhIpJHRICRaOYmAYZzsFnzf84pkwpFOv4ONjghJvEH2aUJGNGnnjbEpoFVxvtQhi8ODykP0MmLxqfF6eNYuMIzB+dCnxkb0kFlzHyOzqPCcRTwt3lEZ6R661qirIGPb08fB4SxaPEdiiwcVvj9SKA9Gz7s5wvEVbnUt8IK4XGHKw11uWiwXlRzoVSoGeQapCw2/73FlX7vy35JAqptoH+GCAovrVDoUt4rG1OOnxK0D33+ZobDRsz811lkNx6g7hCKbOEqlgAzk3lUSXCwn0K7YlwsizohHsH7PImepeI+ZoovWpw/sbMpH7refJ62c6AkVW5QbbQBTxsnli/92Ax0ko4PW8mSpbeRpWksKckg6FqRWZXZ6ELiRQWoq7p/HydKux+pH9u5Qbt7eTjH9Rxm+ALa8Uqof8q+C97G/13z6Puun1yKmlIHyUZYpjWL2OBYYvGIautuZEVMMFqK307TpYCjTHDsdJCRT+7ArRdyRqWhSLrPNXWZ7D0Vt5XjtIsagUIzIGaPnNgb2QJzLPCLMykw3Cf2EeIG6FkJRAKWFD2e6Ikv0dqx0TsU8wCjIqONYpuSNQWeHaYqCoLzrHJip2fnLEJTI0FNhNS0yVL+JrN0HgMUZam0biP0BYcYFE/3XLnwrmlsdWYCJ6fnP3fRK6tKQEqf7U0zPPvcerIwL7+2sE/VfALwE72T48+Dcue8b/Npg6wqYsy3LKeKltTH5kK9pWMOJVaUt64lWtqbCpCJyeKD15MvWKeY0Z9ttFuLxFRWHyydERku2SlkqCRublpVJU4W8gwDpzzLbyuWCVdrcQqcV8HCrxEzJUWgHJQemNIz/3kShzaop3F71v39K17+tY9/dPdU9Ie7VT4F9FJDevnXjJ9udU2aZF2Svp1dlNpQ7FTBV9B8xG7i92ifplNSHb3prNT0K/xZuTLi9dggeYDPPrro0+y7NKT2KWJ+Fkw6+pRoNF/kUs/kW3qFNNPlHe19ZumEmSs/At8eX95+PJzf798jPa+lK+XTzPssB2DY/qkm3xbH1qSICpmNBv/dPTDfw9/YM+YA2D0uMM52OQBZwbZT6bRwfwvXvyrPl/HDEKcbjF+R+JyDhbYUjjfYZmJggVbSpyzlWksi0PLg3+Pd/QZ1U990svUUK/KlIO3d896qN19Y0p6u3CzrWNVN0vt8WAk7ZOzidNwYPZQ/pZGDxz5nIrhwzL8nmjoyXkyVfduzjbnS9/5OCcmCtixRloMILBwNwjbBzwLE/ecj9b3ZvLtSNRydPN8FNcORut+TaAd+XETNU72ptslaKziOZ8j1i4fjURdH9TWVAd9qBwglHPvYN2iwgWFZ/Cc0yWOYWrBzY+M+SBTA4ta/gqrbkOgDK+z29UFjxVqXBHfttn9/YeeHnHI404B/Z4EgDZO6ca3KwPHHwXdGXg/8udR7G6O70fzmyfzwwn8rZfeTtHDCkIckh/ezsAPhxPuADYYX/ePBqPp8PTuzJmetj4ZTI1XQh/c0SysD/OMx9WVwesui7B4ZSLvBOuCl928ODg8OCR918bhQvisGy3zMyCraJ2Gll/Yd6Rb2pEhFX5/tygkmfxv2LKJhiaUUa2E1MSgd8919Pcrnm/aQRG1JPGe+3D1Ts8znqfbMd2YdW4okV/x9XoiHPxmVdvS4z8bIPVdXVMIW0mx52Ojkj4Oq95lHpT+u3HME9+zhyTp4kKvQqZo6BfP+AdYDXZ5KLd/xoPvK7S99qsdovL7R+sIdxSOfHYZcl9H5179JvYDBgVyjVthr5PE9vPxJc/4JO78xMi1YklWFcvAsqn7WuafrbkSetYIGt6GYb3Pqd3HrG5vI6SKrPsnqadDpazXAcK3zW3b6yh04rTg0P4PdmxgPQ== sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Returns a user-facing textual or JSON summary of a report file. --- --- id: invariant-instance title: "Invariant Instance" description: "" sidebar_label: Introduction sidebar_position: 0 hide_title: true custom_edit_url: null --- import ApiLogo from "@theme/ApiLogo"; import Heading from "@theme/Heading"; import SchemaTabs from "@theme/SchemaTabs"; import TabItem from "@theme/TabItem"; import Export from "@theme/ApiExplorer/Export";
Security Scheme Type: apiKey
Header parameter name: refresh_token_cookie
Security Scheme Type: http
HTTP Authorization Scheme: bearer
--- --- id: list-integrations-organization-name-api-v-1-integrations-get title: "List integrations" description: "List integrations" sidebar_label: "List integrations" hide_title: true hide_table_of_contents: true api: eJztW1tv27gS/isEn84BVCctCuyB39L0crynTYM47XkIAoGWxhY3FKklKbteQ/99MaQkU7Z8S7q7bdGnRPJwON/ch5JW1LKZocM7eqmkhMRCSm6gUIZbpTkYeh9RVYBmlis5SumQCm7sSFqY+XsmjpWeMcn/cJexZDnEMSt4PH8e85BuBpZG1EBSam6XdHi3or8u7EWSgDGvgGnQdHh3X91HtGCa5WBBG0eFLOmQbm1DI8olHdKC2YxGVMPvJdeQ0qHVJUTUJBnkjA5X1C4LZGCs5nJGI2q5FXjjY8CRXCHHCrfXYAolDRhc++L8HP+kYBLNC6SkQzoundTTUpCbmphGNFHSgrRIzopC8MQxPvvN4JrVtjxMa7ZEEBZyt1ehUdWW+50D5W3/WJY87YM2VTpnlg49wRrqJ7ysoq4ST2XS0VfDMWWWbcvnWa5QJwY5zbjNyknMiiLm0lgmhAe2Zn6LK6qoh7IHvQEdJxqYVfokLRjQ5LJeh3tl+7g0q95l4ZpQ/Lhff83CUUBKRk5blukZWAwZb+PG9F0WSNj1kVZLbj35iOvX7DRG7FP4uZBHMvhideijavIbJDZY8MYRVGuOLcU6/u66BuroeVuBXaVsYGokug+12sbFa2bZO+cvF0URaht/OCik+63X4U7czbmFiVli+RwC5U2UEsBCJx8ZcuGpqog6lUAaM7vXh1Nm4ZnlLt81fC79UnJhD5vCh8B24NehG4rekalfCSi4DgtE6HXfV44KEuzJ2wQaaXfpz3k9Kc7YcrLXTcZIUEW01GJffvmkRZAx0So9IENYDjHoEIeT3FfY3Rv52hjRaSlEfIj4bSkEaVZkNhfxARj/tbkgNZZOnV1RJpcfp64J2Exo7R1ZCkGrwFlfByy8dg4J8I7bZn9jskPUY5OtpZ2yUth4oplMsn2LXntK8spTVhFlOsn4HNK9jnDREOFm3LCJOLDgdUN0tPckQkk4hPkSiTzqA+nGRUndna3dJXCEro3X9lnrfkuvgbICNXiAIYD7jkmzctJ2sktE6rntTVnHBkKi8pzb7fUm29twjrPDVQlZbAG59PsdWlvrupZui8va+XZ0A68aDWEkqNCvT24sxip0drOUSdyr/6P5LWVC1vId8sLN1B411d7l3sZ1wswZ+EcH/Kbwe5zMdx0/eC/Qjakd1uqMkK7iMVv2xNvXL/WmdMBPZjb2604ca8IZra/OM9ubTkCWOdpDPeCF1kp33AokaJ6M3eqqIehUw+Marc3GqpF+F10rd6NDLfdms0Zl2hXa+vYe9u6vK5uW8d5601qnYMYslE47JdStiuhCcwsfpVj6SX+nsabcy/OYJuItF40Jtd3UPUz5l5FPYHdbvVXAtb11vxUoOWs4vIhozmVzsU+msZMFHUKm34hIb2Tqkg5LU45BwMR1YAJ/DrNzkkS3HsmpciOl2WgM6kmToGnJVGliM26ICwXixjSZwIBcCg7SGmIyVYqUCBwdxZKk3BSCLf0ax2EOesIszwcni9uTP5tSEoRJA6t17top73vwbiHFY4lnU5ZwOSNGssJkypJCKzxjwnsO9YDcZkAu34+I0uTTiCwc4pw9gIfJpQ8eTIZszrjALolYRWwGBOfxQY/DVxEVzNi4NI+rPe+ZseSTqatPRHOV8il/HK8P9dpjCllbzDFFNhlyA0tXmtAQXyxoycTYFSUs2hvz7d9TjPuqcKd6tUW5vxB3YXQgHN8d0Y1pvi3V/dP//7nN/H5BxqfNGSh5z40Nz3wJ2TpiJeSi4OTzcxKeIZN3gPpCuV+eP68L7HFnqRv9d9tn7Jx4A/E3inmp5ZDLOdOcSTt0PmWGrLRZnGRMCJAz6CmWX6PsbZS45pRRJo+uX6NmPbpzKz12XBJ6e4hNZSDuvp6GCaEWkMY52Eyl3V7+WN4TZngS4w5bGxwT9wHMV8jporTZezXj8oOTyellvwCKp0kPtuOmv+NSk+MVSHpdTgRPnI1Sjsk/57I5eK6FXV75Bx01h5wVBe4/XIUKO9iS/uXK9do7KMc/qOOq2j2ZXHj/JR9q/z1yq023D3ZFDcnLIEN0i/ttXX5JXhpX1ec8BcJIoXnO9JKgpUDaOsORREOKl0wMjnBkCYtYoHWeausrWDgrH4sjUXkhwAIxIKbPDOg5T4A4UYiGGTfWp/ZjQMyZ4FhLY8h95/QkJJ9rbm+Q2SlmAYJFRytB1NQ1TU4cwtJUgzFksiTXoysyganSQGaMS2zNmHsQ2LRZLElUKe0xoDUYsHHxdMtd15PSDTK8Hl39ZZBdQwoporaKOPndmmZUO9Zfe0a7RwEfg22wnx59Ehat4F/NpgZsWcSJSrf7hNOxlcWlSuFYZCgplxzzxhqXH5taCA1Oyx4cTLkkTmKCJz5KmqMguhn0qeiQyX5kiRvsmrlu7Ww+wxgcjHDOkWkw6zXua0CAQ0RMogEwBwWbd/Y9uRL7tuhg8fvZPf3snn52T/909xS0RwcV/l10Ut36eRSm77faBi3SQaQ/ZjcVNhQHVfADNB/r0/YfsgmJNiedg0B/xMnIlRenwdiqB3j0ax4uyZJbx+LgM3V/5tee3G+d1a+PyPo6xfYdTyf7xtm9xBKkNP/Dv3Tx8vzl331++RjtfS+nl08zbLcdA/cEJnhht2tJpEiJkuTm7eUv/zn/hTwjBoDg7WbNoM8DrpQlb1UpvflfvPimjq/rDNL/fLo1fsPiNgMNZMGM67DUREBOFtxmZKlKTVDxYOzg2/GONqNiBaG7X+sRKqGPeenkvUrcUy0z24fsg5mF9tgZScfkbJTUbxjtyt9cyY4jX9dPhXdg+Bxo6Ml5MlT3Ycn682X9YNM9nnwjLX4LsE2GT5JI+CgJteJnqCH1XxK41/6H9Gy19WFAdcYKfjZ/frbBAJvr5qMC98IbzawtzPDsjBXFoNAqHbQBNLCAry7dr79YGGPQen/6dWFvYKrBZJdKPfDQ7Kzg/4Nl82lC4n9uBjeq/Spf+eL61yra/hCi5YcS0vpjBryeeILKxdHUvfC5jotadtJGCD5RzHFQ6vzcBCCppw00LGjjNT9/MTgfnKNQhTI2Zy5h1eL3WWXjjc1abAtf7FkhGJfBm4jeYnd02PcpBys4yvHcqS7Y4T6imcLsdEdXqwkz8EmLqsLbv5eAwO7u0S81R4dypl2/KDllwsCWiG1ypv+6qZ3/34RG/aI3ZpVL7/4lXtGIPsCy95sU90w9A5a6z1lWNR0at7ABh62qgJ7WOvi7N7eokfrEohahtnzU/BMkza50q5WncL1RVbXC+naruq+q6k9kywFX sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List integrations --- --- id: list-monitor-targets-organization-name-api-v-1-monitor-targets-get title: "List Repository Monitors" description: "List Repository Monitors" sidebar_label: "List Repository Monitors" hide_title: true hide_table_of_contents: true api: eJztWt9v2zgM/lcEPd0BXtIWA3bwW9frhu7WXtEfeykKQ7GZRKstaRKdXBb4fz9Qsl27SZu0vdvWYU9tYorix4+kaDFLjmLieHzFz8BoJ1HbBTvWiv5x/Dri2oAVKLU6ynjMc+mwfnoh7ATQJYm2E6HkVy+UKFFAkggjk9luUgTJBGvRCSCPuIO0tBIXPL5a8g9z3E9TcO4tCAuWx1fX1XXEjbCiAATrvBRp5TFf2YlHXCoecyNwyiNu4UspLWQ8RltCxF06hULweMlxYUiBQyvVhEccJeb0xd8djeyENFa0vQVntHLgaO3ezg79ycClVhqS5DE/L73V4zJnZ7Uwj3iqFYJCEhfG5DL1ioefHa1ZrtojrBULAoFQ+L2MJX+jDDuXpczWWT/WthDI4yBwi+aSPlZR30+PVdJzSaOxABSZQLFqY6Dmfg8Hp5JriqJxjVr8Pfa89hdVUfuNKvOcExONmoN6eUXkNIGalDZ/qsJOuF/a3GOso9UH0xO11rnBTklHFXEFONf2Jmm89BSdJ0FHE55RI6hHnyHFXthfBTpWDQrJetywWEVcukSkKGdd8kZa5yBUh70jx/aDFFFoQSBkicAH4ykTCK9Q+uxs6QtL2T5uRFCH42oMd6Kwa37PrvuQk/m3zId8ZR+lw5r0ukIxtlIQGNs3kn3abYoiq+see09aK0LzemeXHLJ18vcTyKHA0nU8KhXCBGzHe+dBpHWc38v53LUqlmomrBQKY7BWWxeLEqdJOhV5DmrSZeGCVt964v6kvfB/q4hngELmD4n+GSQoopRDodInx/lRs55CrbU+XnKtoFbW99xdZxButQauyHM9hywpAKc680vbgrut7pFwMk1oh5UNNsSzf9aB+ZY07Zc4/agnUh17m7xfHjZAyyxdg2278ruNidFK7TgtR7lMPUeZpMOvkEqgtp0YXpyEk7nWUAhjaP942XXYSsh/c+cG72204zv6uOqsb7qCRmY/xC87ruN3y63uhn1nV/KQOuhUiH5zczEFVjqwrCgdMmP1TGbABDNWFsIuGDEFCusKx1ILGX0U+WCLQFYwT3Ji57lcn8Dcs7wtjlQXJgcE5iAfv3JgZzIF5k1hFibSYWh0twExE7mkcy6BgqrfM5F8qrUdkrLH0AKMDh2rc6bHDKfAvDlMZJkF59howU6PTtgIxtoCmwippJow4TtXhtqvEGmqS4XbgLbgABPzfOZOhXNzbbMzUnh6dPK/QTZWpwAZoUbNvP1+jakN2DZeG/nnAj8HbLA/PvsUzFvD/zNOHWBpklRnq33C47GV5kBnsC0yslQqSXXjFtdY2y6EBieKGw9TLZi3mFHzp5XbCiIKi89GR0oeRpbmEhQyN9VlnnWCLVQYB85RsRQqY5l0JheLTvg6yMEjYi61AFSDui8/3X0ffRKHtmjj4fere/rVPf3qnr5399RpjzY6/EV0Uv3zcytML/e07bRIG5H+nN1Ut6HY6IKfoPmou4vNUF9mExLdfdPZCPRnfDPyx4v3YIL6BtRTb7h8kWUXXsUmT9TXglFzHgUd7Y1c94psXafYDiW87X1vXSo6grSVX8Ef7693Xn/r+8uneO+l3F4+j9h+OwaHdKXbmTD1mSSJjGnFzt4dvPlj5w17xRwAo6+bNYN1EXCikb3TpQr07+39UNfXdQUhSx8gv1FxMQULbC6c77D0KIeCzSVO2UKXlpHjweHgx4mOtqLSCdJ7mer7Nddp7+ndve5rdz/q1A+z3OQhZMdu0uXj3kzapmaTpWHD6L76LbXqBfIpHYb3Y/jU8dCz62TX3ZstW18vfefjnBjlwA4V0vB6VYzGSWzdFN0PruhVKuZhAh4mjHy4XBloV0Nh5HC2O7wzOvdjcztr5uF+7smniMbFw6EwZmCszgZtKg0Q0qkPwGbYfk7pGyLrwxzPYGzBTQ+0vpHdABBG/gWLZqqehsfNKxy3YVU4A5P6aRWtzvBbfWQhr+fw9HkUBCqfUWPtJdsMqW1nba5E3JUFvTL1HjepyOr3DqIYrAsczPYGO4MdMspoh4VQtyPqh/jpEdlaj/APDk0upCKF9aw5cHfF43U/RhBGkjm7/Haa3BB4HfGppop1xZfLkXBwafOqoq+/lEAQr64pVq2kIPMkZ9IHXMbjscgdrFjZFmz+21mdEL8zHq23viFYLUJKlPSJR/wGFmt/WFFdVxGfgsj8bzKWtRzRbLCjYeWkoJhro/394QU5pb7FaIbMIQai5p9OIe1bt1wGCd8vVVVrbGjBquuqqv4FiWwVgQ== sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List Repository Monitors --- --- id: list-networks-organization-name-api-v-1-networks-get title: "List Networks" description: "List Networks" sidebar_label: "List Networks" hide_title: true hide_table_of_contents: true api: eJztWt9PGzkQ/lcsP91J2wRQpZ72jXL0RK+lCGhfEFo5u5PEZdd27dnk0mj/99N4f+AlCQlw15aqT5DsePx934zHs3aWHMXE8fiKnwLOtb1x/Dri2oAVKLU6yXjMc+mwfZok2k6Ekl/940SJApJEGJnM9hPV2kwAecQdpKWVuODx1ZK/neNhmoJzr0FYsDy+uq6uI26EFQUgWOetyB2P+coUPOJS8ZgbgVMecQtfSmkh4zHaEiLu0ikUgsdLjgtDDhxaqSY84igxpy8+BB7ZKXmsaHoLzmjlwNHYg709+pOBS600ZMljflF61OMyZ+eNMY94qhWCQjIXxuQy9Y6Hnx2NWQZ4jCUpUdYztALR/xKhcKsmZSmzdUTG2hYCeVwb3BL7SB+rqC/ZQ5301Gk91rHYLGmtYsQLQJEJXEM31UXRqqQWH8Y+xH13VdR9o8o85xSUdoKjZnhVRa2NHn2GFEMQtaLvWwxVxKVLRIpyFoIfaZ2DUMHAE8cOa6sq4qkFgZAlAu9VLRMIL1D6dOxA1kPZ4Xqct5l61Yq+GqlG60DKkEUP3vUKdX47q7BWLFbFcVuRqWDpt4PfBYs+yPz+6iAjpscsmInmerm3X8f/UavEocDSBZGQCmECNmB2UZt0tPxczme2VbFUM2GlUBiDtdq6WJQ4TdKpyHNQkzB6lzS66j5vTvZL/7ci/ihkfp/pn7UFZaJyKFQKj10AJ+14StEOfbzkWkHjrK/cXTGIt1pDV+S5nkOWFIBTnfXL0a6+R8LJNKEZVibYkm3+WUDzNXk6LHH6Tk+keu8xeV3uB6Bllq7htlvZ2gVi4ytAelaOcpn6GGWS1kEhlUBtgxxenNZbWOOhEMbQ/PEyFGwl5b+5uLV6W3F8R42ranNhO6zzl71v8nfHqe6mfTArKaSOggrRr3OXU2ClA8uK0iEzVs9kBkwwY2Uh7IJRpEBhU+FYaiGjjyIf7JDICuZJTtF5aqxPYe6jvCuPVBcmBwTmIB+/cGBnMgXmoTALE+mwbgJ3ITETuaT9MYGCqt8TmXxqvB2Ts4eEBRhtOlbntCvhFJiHw0SWWXCOjRbs7OSUjWCsLbCJkEqqCRO+xWOo/QiRprpUuAtpCw4wMU+P3Jlwbq5tdk4Oz05O/zfKxuoUICPWqJnH78eYBsCu+draP5X4BWDL/eGrT8G8A/6fxdQBliZJdbbaJzycW2mOdAa7MiOkUkmqG7e8xtqGFFqeKG48TbVgHjGjblErtxNFFBafzI6c3M8szSUoZG6qyzwLkq2uMA6co2IpVMYy6UwuFkH6OsjBM2IutQBUg8JXg3DeB+/EdVu0dfP71T396p5+dU/fu3sK2qOtgj+LTqq/f+7E6fnutkGLtJXpz9lNhQ3FVgl+guaj6S62U32eTUh0901nK9Gf8c3Iby9ewQT1DajHnnD5IssuvYttSjTHglG7H9U+uhO58IhsXafYnWF67H21PiragrSVX8Fv7y/3Xn7r88vHqPdcTi+fFth+OwbHdKS78UCaLDKmFTt/c/Tqj71X7AVzAIy+bscM1mXAqUb2RpeqDv/BwQ91fN1UEEJ6T/BbF5dTsMDmwvkOS49yKNhc4pQtdGkZCQ8OBz9OdnQVlXaQe27Gcp32nt6da1O7+06n/prKTe5j9t5NwnhsXEm71GxCWk8YbarfUqteIp/RZriZw6dAoSfXyVDu7cjW10vf+TgnRjmwY4V0y7tq5m+Huqshf71F708xr++H/WVuzIfLleveaiiMHM72h+p2MDXV7TVxaXMe8ymicfFwKIwZGKuzQbdwBgjp1Kdbewd9QYu1zqO3czyHsQU3PdL6RobhFkb+DYv2sjmtH7cvbNzWo+odL2meVtHq1XbnjxDy5nqaPo9qg8qvn7H2lt16aLCzbmVE3JUFvSD1HrcLjzVvGRRQsK5WfHYw2BvsESijHRbCF6oG/t1o9GLVQUb4B4cmF1KRFy/0sonUFY/XXcwLIwnDPgkV3CNONVWjK75cjoSDjzavKvr6SwlE6Oqa8tBKSiAf0kz6ZMp4PBa5gxV4XTHmv503yf4749F62G041aJO95I+8YjfwGLtrwuq6yriUxCZ/2HCsrGjoBoMPKzsApRhXVL/dXxJajQnFO3Fcx3xqP0nKJJ9dMtlbeF7oarqwNbtVXVdVdW/m3qygg== sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List Networks --- --- id: list-notification-groups-organization-name-api-v-1-notification-groups-get title: "List Notification Groups" description: "List Notification Groups" sidebar_label: "List Notification Groups" hide_title: true hide_table_of_contents: true api: eJztWm1v2zgM/iuCPt0BXtMWA3bwt67XDd2tWdF2+1IUhmIziVZb8iQ6uSzwfz9QfqncOC9td9s67FNim6L4PKQoWvSSo5hYHl7zoUY5lrFAqZXlNwHXORh3dZrwkKfSoi/y1ugit1GkzUQo+dXdi5TIIIpELqPZQaQ86WhSiU8AecAtxIWRuODh9ZK/m+NRHIO1r0EYMDy8vilvAp4LIzJAMNZJkWYe8pXZeMCl4iHPBU55wA18KaSBhIdoCgi4jaeQCR4uOS5yUmDRSDXhAUeJKd344GlkQ9JY0vQGbK6VBUtjD/f36ScBGxuZkyQP+WXhrB4XKbuohXnAY60QFJK4yPO0hj/4bGnM0rMnN8QvymqGHq7otkTI7Kp0UcikD9NYm0wgDyuBO4wf6bIMuuw9VEmHqEZjBigSgX2InMPW815RTYRlWUOYWnwYO293B5VBe0cVacrJP42a43p4GXDIhEwjFGYCaLv6Wh7vK25uCGPEYuNEJ6SdXdXay4ArwLk2t5EtRm1YfPtph9Us7LIzS3mnQo8+Q4yd0L+uyPe13F+4Z43fyoBLG4kY5cx310jrFITy/HVq2VElRU4zIBCSSODGCEoEwguUbpW2DquGsiPciqIOwNWo9eLON79j1yb0Kx7ol2VVjtvOds/i9aZ/35s5vZzRzSskzvSYrQ7hZUmmvNw/INYfmWksCiz8oJQKYQLG4+CyEmlRu7msSwlGhVLNhJFCYQjGaGNDUeA0iqciTUFNfFdf0eiyvV6fC67cb0lMoJDpJtG/KwkKW2VRqBgemzlOm/EUz6314ZJrBbWyLnP3ySDcqgeuSFM9hyTKAKc66ebxXXWPhJVxRDOsTLAlGN0zD+Zr0nRU4PS9nkh15mxyvGw2QMsk7sG2W1bfxcRgJUmdF6NUxs5HiaQVkUklUBsvhhfDqgyoNWQiz2n+cOkTthLy353cir2tdvxAjstyfQo8quKXndXxu+NU98Pem5UYUsdehuhmvKspsMKCYVlhkeVGz2QCTLDcyEyYBSNPgcImK8cGEroU6d4OgaxgHqXknaf6eghz5+VdccQ6y1NAYBbS8QsLZiZjYM4UZmAiLVbV9S4gZiKVtJlGrsZ5KpJPtTZX0jzELcBo0zE6pf0Jp8CcOUwkiQFr2WjBzk+HbARjbYBNhFRSTZhwZTJD7UaIONaFwl1AG7CAUf50z50La+faJBek8Px0+L9Bzo2OARJCjZo5+92YvDZg13ht5J8K/BKwwf7w1adg3hr+zXxqAYs8inWyWic8HFuRH+sEdkVGlkolKW/c4Rpr40NocKK4dTDVgjmLGVWYWtmdIKIw+GR0pGQzsjiVoJDZqS7SxAu2KsNYsJaSpVAJS6TNU7HwwtdCCg4Rs7EBoBzkv1P58z54J67Koq2b3+/q6Xf19Lt6+tHVk1cebSX8WVRS3f1zJ0zPd7f1SqStSH/NasovKLZS8AsUH3V1sR3q8yxCgvtvOluB/opvRm57cQxGqG9BPfaEyyVZduVUbGOiPhYMmv2o0tGeyPlHZH2VYnua6WzvsvVR0RakjfwKbnt/uf/ye59fPoa953J6+TTHdssxOKEj3bVH0ySRMK3YxZvjV3/tv2IvmAVgdLsZs9cXAUON7I0uVOX+w8Of6vi6ziBk6QbnNyqupmCAzYV1FZYepZCxucQpW+jCMCIeLO79PNHRZtSmO7WmpZjquPN0c8fKzzGx6wPaySZkZ3bi+2PtStolZ5Ol1YTBuvwtteoE8jlthusxfPIYenKe9Onebll/vnSVj7VilAI7UUid8lUx1yfqa1e57hi9SoW8are73njIB8uV7nk5ELkczA4GfS0sKq7MrGnAFyblIZ8i5jYcDESe7+VGJ3vtctpDiKcuCJvu/iUt4Sq63s3xAsYG7PRY61vpB4HI5T+waNr4cfW4eY3jphpV7YNR/bQMVj8aaPWRhbxu/NP1qBIo3aoaayfZrpLadtaul4DbIqPXps7jZjmy+t2D3AzGVn6YHe7t7+2TUbm2mAl11/3e5KOOM1vrEf7FQZ4KqUih43xZ+++ah31fP4hckjkHxFl/H3KqKXNd8+VyJCx8NGlZ0u0vBRDM6xuKWSMp2JyjE+kCL+HhWKQWVixtEzf/46JeGH8yHvQjaJysFtXSKOiKB/wWFr1fc5Q3ZcCnIBL3IciyliNX5+hpWNkxKO7aqH97ckXE1KcZTUe7ioOg+eMl1K51y2Ul4eqmsmyNrUqx8qYsy/8AdsVDzA== sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List Notification Groups --- --- id: list-organization-members-organization-name-api-v-1-members-get title: "List users" description: "List all members of the organization. This includes both managed users and invited users." sidebar_label: "List users" hide_title: true hide_table_of_contents: true api: eJztWttv2zYX/1cIPn0DVCcpCuyD3rIsG7I1FyRp9xAEAi0dW1wkUiMpu56h/304pChTvqdJurbLU2KbPPfL75CcU8PGmsZ39IMGRc6ZYGMoQRh6H9EMdKp4ZbgUNKbvuTaEFQUpoRyC0kSOiMmBSDVmgv/NcNmA3OZcEy7Sos5Ak6E0OSkt0YzUGncxkREuJtz4bwY0orICZQmcZTSmBdfmMqB67hgmScgqEayEJGEVTyZHSStTMgZDI6ohrRU3MxrfzelvU3OcpqD1T8AUKBrf3Tf3Ea2YYiUYUNquQmo0piscaEQ5al8xk9OIKvir5goyGhtVQ0R1mkPJaDynZlYhAW0UF2MaUcNNgV+EipALpNggewW6kkKDxr1vDw/xT9/eN7WVelQX5LpdTCOaSmHQPfGcsqoqeGoJH/ypcc98VR6mFJuhEgZKy6tSaGzDHWf0wJpva56t02kkVckMjd2ChY4f8GMT9a33WCI9Q3mKhRzzBSkmZpcj667tRJuoWyHqoqBocM/mPVLs6EPJeLFVSrdisf/Ufm4iWoJhGTNs1XxcJ7quQHnjtrSHUhbAREDrTJObbmETUQGQ6cRlR1Jw8ZBMQGnuXLuiPBcGxnbjZm0vkCI5sxTJey4eyMeWYoOBvWAEnyquQCfM7GnojBl4YzjG8xb+IedTx4IcG9o0kd8ih39Canqpdde3YEAOi9S5tztqoBOWGj6BXWY+dquaiKYKmIGsVXQP9RZ0TtxWqwBWxwIWhJ7NYj87svtYqU2g1azr5U3UhXAXsaHhehZZMnWXgX0Nn6dYvEjqsaKQU8iSEkwuM92Xu6uBUsBaVZwkcyyyGgUYMs3ThNW29HspbnHRLtfY3wJr/oSUjmuT2/JzbqWzYbBdAMmzdIX1S9RZW0vU5xE8W+xt6e1jnPVxuyJHYMPLs59PeuZDiMKxZZZcMCPDRja7cP28ZVWyqkIl4nno05Xo+eL+dw7eKcdrGGwLgyZg5ODOtvp67CoEOW8rhK9EyYQVHEt0trWX2BpEPnZrWx8mleIi5RUrNtWcvoe/dtdFtFMoWU/L773y68jZbpfv5esl3kuu7/jRx3j9kmcpuVr4CJsIjiVcjHGqeC5wed7SJJdqvAB0FdN6KtX2wHJI7cov7TZrMHWVpDKDZwKDN0iQnMgMQiwYsHkhKBjwDZHgK+rtsmO5Dq3Ez/IYcyLFiI89IL6qhwVPX2HxU1BvYNbOnMtC7eSPyNkD5/v1ZdsdafzBTX76yShmC5Jf56d9gicuYcX0By9k5UyBkOOKk49HpD0qIb+CaRvju8OjFkrsd27Q71PaMFMHmKRLvyCv3ZLOKAvYUisRczFhijNhYlBKKh0jmkrSnBUFiDGsQTXt580d59b+taFmNowQi6gx7cjAhTZMpLAtKLendLsfc6WT/hGzBOot1qi7ZmL5buYUd6i22T3tcdheMNHSCiT16flfHwK+hI1XEfYWPL0fq+WwDxE6ZspJUCH656K3OdiDY1LW2pBKyQnPgDBSKV4yNSPoKRCmrXAkVZDhR1YM9ghkAdPEFe4n+voCpq6X7KlHKssKOxzRUIzeaFATngKxohAFY66Ng8j7KOERRLJ8gPJZmvhZx04+j3ELEGw6Shb+psCKQ1iWKdCaDGfk6uyCDGEkFZAx4wKBM7OH3sRIu4OlqayF2UdpBRpMUj3dcx6CXyPBq7OLF1O5UjIFyFBrI4mV3+7xcG/feO3g4RMVvwHjdX989gmYdoI/m08XQ8kz6FZXOHvsqxlKygXHurHQayRVqILX07AHq6aYESsxQZAphd5LRcOUebJ2SGS7ZmnBQRiic1kXWRBsrsJo0Dge2cu5jOuqYLMgfDUUYDUiOlUAWIMC5j2+j+7EDhbtbH6v6OkVPb2ip38bPQXwaKfBvwkk1e+fe+n07XbbACLt1PT7RFMhoNhpgu8AfLToYreq3yYIiZYnnZ2Kfo+TkW0v7r7fyAdYf2q+xwmXexhza0nsskR7LBj5fuRodCdy4RHZOqTYvWeysvet9UFgC5KK/+1u194dvvvS55efY71v5fTyaY7twzE4xSPd4HFa35O4IiNSkOtfTn78/+GP5A3RAAS/9nsG6yLgQhryi6yFc//bt1/V8XVbQVDSLc73JG5zUECmTFuEJYcFlGTKTU5mslYEDQ/aDL6e6OgqKnaQ3jDVt2sh096vy7w2wd330t5PlXq8TbNzPQ79sTGT9qnZKKljGG2q31yKXiBfYTPcrMPHwEJPrpOhuXdLtr5eWuSjNRsWQE6FwXevjXskhRNSTN2bWPuANaYH85Unrs0Bq/jB5OigvV+yD2jVxL+MrVVBY5obU+n44IBV1aBSMht0mTEwkOY2nvyz2xvMRhcov03NNYwU6PxEygce+pNV/HeY+fe1qfvZT2RUuV2upSXtr020+pq3o4cS0vZFLn4eugWNTZCRtCsX97NOdtKFfkR1XeIE1PvZZxZpxwj0mL+bppO3g8PBoX0rIbUpma1Erfj2sbR93rxcFoNa9qJPqlurGPhkDqqCcXv3bX05b2PhjsbrnjuziqOaR/bq1AXEfURziQXtjs7nQ6bhgyqaBr/+qwY02d09hrLiGIM2aDJu4zGj8YgVGrbY4H/Xbb78QDZJ7QNGzFzG1PiJRvQBZmufbDf3TURzYJl97T1v12HYVCagsNJIMIa7rPn19BaN0R5y+Et0F1OR/yeos33p5nO3wsKppumEdQgN75CbfwBIZX7X sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List all members of the organization. This includes both managed users and invited users. --- --- id: list-report-tasks-organization-name-api-v-1-reports-in-progress-get title: "List in-progress evaluation tasks" description: "List in-progress snapshot evaluation tasks." sidebar_label: "List in-progress evaluation tasks" hide_title: true hide_table_of_contents: true api: eJztWt9v2zYQ/lcIPm2AaqdFgQ1667Ju6NZmQZJuD0Eg0NLZ4kKTHHmy5xr634cjJYeKHdtp9qtFn2xJx+N9dx+PJ57WHMXM8/yaX2phfW3Q85uMV+BLJy1Ko3nO30qPTOpn1pmZA++Z72QZLIRqBIkxFP7Wj3jGjQUXbr2peM6V9HgB1ji8IoGiMG4mtPwQJAot5lAUwspi8bxwQcwXUhf9TMUMkGfcQ9k4iSueX6/5T0t8VZbg/XcgHDieX9+0Nxm3wok5IDgfpEgzz/nWbDzjkjBZgTXPuIM/Gumg4jm6BjLuyxrmgudrjitLCjw6qWc84yhR0Y1fEo3sjDS2NL0Db4324Gnsi5MT+hl68bIJVk8bxS46YZ7x0mgEjSQurFWyDIrHv3sas07ssY4cizLOkPgoXCLM/bZU08hqF5apcXOBPI8Cd9je02WbDb32WCUDB/UaSwcCoSoE7lVVCYRnKEOYen2ncSh7haSocXpfdN47TVLx8cNiV3S/JSpIlAKNKw7ofdMLsm6GpXG34AprdvqmH/ZbkGLnJjhhKXxxK5WCdMzEGAVCp4OEZz9HsXaDhZvJ71DigLLXveu34zXwePRap+k+6AGUgY03dybdreA773LhnFgNfMTOe04eMjzlbzLP22G22KyTtiWFL0+ek+M+csl4FNj4xPNSI8zAJQguo0hCoNJoHzjudC71QjgpNObgnHE+Fw3WRVkLpUDPYAe9uus9PAy/LSVcFFLtE/0+SgTSehS6DIqFXv0yDQlvOK7NNnd0oxRvb9I4deNpXW6sz9fcaOiUDT133xmEW++AK5QyS6iKOWBtqmFiOlb3RHhZFjTD1gQHKBWeJTC/I02vGqzfmpnU74JNwS/7DTCyKndgi/vJw+HpdoIjTOx0JZaeNxMlyxCjStKWMZea1mfC4dVZ3M86DXNhLc2fr1OHbVH+X3du9N5BO/5DH7ftwwnsVeQve9fx98ip7tM+mZU8pE+TDDEsCa5qYI0Hx+aNR2adWcgKmGDWyblwK0aRAo1dhmOlg4ouhRodQWQNy0JRdJ4a6zNYhigfi6M0c6sAgXlQ02ce3EKWwIIpzMFMeoz14TEgFkJJKgoKmFP2eyKSXzttr0nZY8ICjDYdZxQzU4Y1sGAOE1UV6uHJip2/OWMTmBoHbCaklnrGRKj3GJowQpSlaTQeA9qBByzs0yN3LrxfGlddkMLzN2f/GGTrTAlQEWo0LNgfxtjOgGP52ss/FfglYI/98atPw3Jj+N8WUw/Y2KI01Xad8HhsjT01FRyLjCyNNZ+6wzU1LoXQ40RxG2DqFQsWM1GSTn8URBQOn4yOlOxHVioJGpmvTaOqhGwxw3jwnpKl0BWrpLdKrBL6elAQEDFfOgDKQcnkg3kfvRPHsujg5velevpSPX2pnv7r6ikpjw46/JOopIb751GYPt3dNimRDiL9PKuptKA46ILPoPjoqovDUD/NIiS7/6ZzEOjn+GYUtpfgwQLNLeiPPeEKSZZdBRWHPNEdC25OR6OOzYlcekS2q1JMjyjve+u9pi3IOPkBwvb+8uTlv31++THe+1ROL58W2GE5Bq/pSDfpywwjSRIVM5pd/HD6zbcn37BnzAMwut2PGe1iwJlB9oNpdAz/ixf/q+PrLoOQpXuC36u4qsEBWwofKiwzUTBnS4k1W5nGMXI8eBz9f9ixyai0g+zpkSlTDp7en+uhcvetKenp3M/2IXvnZ2k89vejDhCaLI0TZg/lb2n0gMjntBk+jOHXxENPzpOpuw9btjtfhsrHezFRwF5rpJYvicV3A57z2A4Ovducj9db3d12LKwcL56Pu17yOO0zUc3kFn2DuHGK57xGtD4fj4W1I+tMNdqskhFCWQdu9d3nS1qZkTQ/LfECpg58fWrMrUxjK6z8GVZ9m7mMj/u3M+7iqLi9Fd3TNttuam/0kYW8a0zT9SQKtGGxTE2Q3JC/s51tlkHGfTOnt6HB436Vse6VgqIHzscoLF6MTkYnZJQ1HuciZKXO/K0vAe5/AHA/cybp7pGfEXTwEf7EsVVC6tj9jZVRIMA1z3e194WVhOd54G9gQQjGoN9YG8pp13y9nggP751qW7r9RwPkqesbYrOTRMPAlUoGSlY8nwrlYQ/Gry66JfM1ewhDzxO9ioumoSue8VtY7fxgob1pM16DqMK3DutOjthiMdGwtZcQdTcL58fXV+Sa7pyjbz1HKmX9nyTVDq1br6NEqKjadmNsLNLam7Zt/wLMrO4x sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List in-progress snapshot evaluation tasks. --- --- id: list-reports-organization-name-api-v-1-reports-get title: "List reports" description: "Reports are the results of evaluating a snapshot or testing a rule. This API lists reports. Each report contains a summary listing the result files for this report, plus an extras section condensing that information into user-friendly key-value properties." sidebar_label: "List reports" hide_title: true hide_table_of_contents: true api: eJztW1tv2zgW/isEn3YAx0mLArPQWyZNFplN0yBJuw9BIDDSsc0JTWpIyq7H0H9fHJKSKN+ddC4p/JTI4rl/PDw8FOfUsqGhyQP9yCwjp1kGxtDHHs3BZJoXlitJE3oLhdLWEKaB2BEQDaYU1hA1IDBhomSWyyFhxEhWmJGyRGliwYRfdSmgT+5H3JDTm0siuLGGaM+yT85ZNgpPJFPSMi4NsirHY6ZnbjSyacWSARdgyABlIE9P2yOFKA1hksA3q5khBjLUHnnmII3nwSzhcqD0mLl3XFpFSgP6aKA5yFzMyDPMjtAkIIVWBWjLwfRpj+L/jugypwlFrYJT0lTpIZP8D/c2lWwMacoKnk7epboeMgRLe9RAVmpuZzR5mNNfp9a7+xdgGjRNHh6rxx4tmGZjsKCNG4XsaEKXRNAe5RiZgtkR7VENv5dcQ04Tq0voUZONYMxoMqd2ViADYzWXQ9qjlluBP3yOOJJr5FhVvUbegAsLOjVgDCIgCPu9BD3rSBswYTrimJx9HjjNg2AuLQxBU2QefpKlELRyIBuwUlianLR6XTjJ5C5IXqGUdL58sULBE6v0WdDhGmxHvuBj/irR+/riygms8LUGUyhpwCDj9ycn+Kc7R+9Kh6ZBKchtGEx7FGcUSOvUKQrBMxfw498M0swjZVu041MALv7LLYzN8oiy5PkqfPnJRRM/oLXlCz5WvS6S92XSAW3NUYKdKv28N7NrT9fwiWxuI9c12mUeNyDPOSrBxE1nwDq0LWqBCOiyZkKkDfvG59u41AOY1mwW2XYqBLlw3KoenShRIoD3U2/d5PjquVWtcPX0G2S2MxceInu6EwsuZQ7faPW4gj4e5jQ3SpTo5oNv9/LtBgl3jUfRvX6NPTh3L+BGzgz+Q1daZssDTF/sSe++qkdBa6UPjnypI8+9+ypc+ccF05BadVjRDivaG/ftbita1VsDY78p2qTAkvAzN324UdLv83Jm2Qo9Xi+zXYabVaTJgrGZYWvttflYa9OFBTemhB2g0LK99BSYePPhfqTnjgALZ1X6/erutLeBBMt3le8n99oRoMbfLGjJRNrU7TurHijJjaNEG0oB6YDLnMvhfpaUAshFTejyrpSQ2Xu1D5czT2TV1pkSQlzHq/V+7cklvywaF6sYAezm81mMrehNaHSgcWOwzM2Epf1gaBU0u7DvkTxCE6DdoSmxMTFt4nWLtC4BlzqDtNTypZzuHAfyRcs2XaZjlYP4rsb7zEk+IePggQ0LjI/Rpzo8iEMNzEKeMrsRiDmzcGS56yg1aPSk5NQ6j4XM831DW3cK11oWgz7MluXewcLuv93ER1DtuGIJ1huWxQj3U25HqW8sbuiJeOF7NyK8nKV+hu86re/g1f0L37zr0WyQTrgSrCkvFrpOUXwH5Gs7ElewYlfS02KBtN34rNNzsbZPM1VKu1GKr2LJmRvYEgouN1Y860MZGF45BtvQFodxIRyLXl503dISHoxdMGEJheceWusN+B+3I1KP2kl/1CGGbSTzqu1eN63CqkK2H07eoVtf2DVcwsJyZFsw+CFOlnGTQsuEywnTnEmbeHclrLSjNBsxIUAO4xR1j9RV87wefffub4UNVsu42DT0ox9RYYfXWCazFy82lzU9TstG+2ROlYSV27BFZ6DdcoW5TAg1hTwdgx2pvDsXduX9xAzPUpSwJGALsNy7yMxfkNNpaUdXasjlJ6fTiqp0UQHF82yFbVvzHdthI+HeBV5xcVM+CZ75RjvHrvmYS2aVjjA8u/Zd/sBhzIoC5Sfz2GFLkP/Lneu9t1WPv9HHVbVxp4n4JZ8CfncUtQj7SCp6SJ5FGaJ7KnI/AnfAR8alsXikN+E5EEYKzd3xIkYKpA0ZjmQacnxkor8DkCVMU4HReW2sr2HqoryrHdjbEWCBGBCDIwN6wjMgThWiYciN9WeVuxgxYYJjEZjCGLPfKy35GridI7N9wgLu8FcrgYfKeNjr1CEszzUYQ55m5ObymjzBQGkgQ8alO1t2R17EKkfBMrfY7mK0BgM2LV4fuRtmzFTp/BYZ3lxe/2kmF1plALk7xlbE6e9oiqDArnitx7/W8Duwte37zz4J00bx7xZTA7Ys0kzly3XC/raVxZnKYVfLUFMuOeaN1i7/gUJjQm2nZc/OTDkjTmPC3HcKZicTLdP21dYhk82WZYKDtMSMVCnyCGw+w4StPmEyJzk3hWCzCL4GRPjywmQaAHNQ3FaL5e69EvuyaOvid6ieDtXToXr6u6unqDza6vA3UUl118+dbHq7q21UIm219MespuKCYqsLfoDiI1QX2019m0VIb3Gns9XQH3Fn5JYX58HUqmd48SGIS7Lk3rHY5ommJRrWI8+j6cjFLbJVlWLcolz01heJS5DS/A9wy/uHkw9/df/yJd57K93L1wW2W46B68FHn6Z2I4kjcqIkub04+/nfJz+TI2IACP5c0/RXIeBaWXKhSunD//79P6p9HTKI/4R6bfBrFvcj0ECmzLgKSz0JGBPs4JOZKjVBx4Ox/X8OOpqMWp8arTkWEyp70aHNlcrcmbMZbrLskxnG8Vg7k3bJ2aipF9hbl7+5kh0g37CNZ4hfIw+9Ok/G7t6u2ep86SofY9iTAHIuLd5GqPzBPu6QEupvKrhrBQk9ni9dPKiOWcGPJ++OwynTsbvXoCf1hYVSC5rQkbWFSY6PWVH0C63yfjM1+haykQNUfRviDqejR8qvU3sLAw1mdKbUM48Dygr+X5jVX99n/nW9JaPaU/k1LQ1vq97yJYuGH2pIw9f6+PzkB1Ruhgz8xxsN4oPupMF+9O1s9LqeWiTsIzBkoI13/eR9/6R/gkoVytgxc6koqI8HcqQ9tuvELEpnh3s4zQSy8M0eF4Jx9xGGA908oPaBJquuy7CCYzzedT4SwGk0Uph9H+h8/sQMfNGiqvBnf8EDIZ1zN13aKx7PMFt1R8apSxPq0udmIn+HZReC+tJJO/YRHzTHwavVWwuff92GbPMTWefJerbJWSyzVmbZr+6rxxGw3N1gmodxOOeKWOulZRitaHLOf87vMUChRRRUCBOyV/8TrVJd7eZzP8IVo1XVKOvrW/xEr/o/Sa8CnA== sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Reports are the results of evaluating a snapshot or testing a rule. This API lists reports. Each report contains a summary listing the result files for this report, plus an extras section condensing that information into user-friendly key-value properties. --- --- id: list-repositories-organization-name-api-v-1-repositories-get title: "List connected repositories" description: "List connected repositories" sidebar_label: "List connected repositories" hide_title: true hide_table_of_contents: true api: eJztWm1v2zgS/isEP90Bal6KAnvQtzRpe9lrs0GS9ksQCLQ0trilSC05Ss5r6L8vhpRsynYsJ7nb3Rb9lNgeDueZeeZFIhccxczx9JafGq0hRyjYFdTGSTRWguN3CTc1WIHS6POCp1xJh7FElhk7E1r+7kUyLSrIMlHL7P44s7HcDJAn3EHeWIlznt4u+M8PeJLn4NxbEBYsT2/v2ruE18KKChCs81Kkkqd8YxuecKl5ymuBJU+4hd8aaaHgKdoGEu7yEirB0wXHeU0KHFqpZzzhKFHRF79EGtkFaWxpewuuNtqBo7Wvj47oTwEut7ImSZ7y68ZbPW0Uu+qEecJzoxE0krioayVzr/jwV0drFpv2CGvFnEAgVH6v2pKrUYadm0YW26yfGlsJ5GkQWKH5TB/bZOinpyoZuKTXWAgUm/ZJjTCzz9vmfLV2uUtYuyA3Oloyk1g2k2jRDQm0CXfYTKLNJsYoEDoSvCaBNuGNVbvC/9kqkgr7eK5uARnD8ojBxji85YGgj28UqJXwaaNUNib8vlGK9StKrFQ2AuPfWCnWYRnQdMGFnv8y9Tk0XNwmy290oxQn1vfqziIVwTtjBnyQ2O/vXDkmfe3KlbVT0SjMJlbovNy16CxIsrdBsk24sHkp76HYSYSTXog2k05M1MiCs15ob/bkymgYw3xKQgH1kujcTH6FHAeF65b7LOmK24ouERGGMV7FZ+X7Db9GzorcEADGAO4GIS2bybLMzwlp0NalxfaStW8i5KaqJG6ud+XOen1dilEHkooNIKdhv7G1na876za0rMi3VsB7sbe9hygTTMzrpb/W8/AxVdcmJrub6zzb6v+99c11zlb2jbFwvbR34l3t7akTV86IHwPw68bvINkZtZk24dJlIkd5DztT9dyxkyBFhLIgEIpM4M4uVAiEVyh9lJe5GZayk3F+dK7YbLBdi4xNH9gUgR7m1OrbMEWwj9JhPDUxtjGkMHZSS/bleDCnsQ9A9hOCN0fHXRvdbxpZS0EU2LidTe86iGxp2Y3VqdT3wkqhMQVrjXWpaLDM8lIoBXoGW/p59/nxvL/xf33DQCF3VtqzIEEs0g6FzuG5ffC8X0/0WlqfLrjR0Ckbem7dGYRbb4ErlDIPUGQVYGmKYTrvq3sinMwz2mFjgxEO+98imG9J00mD5Uczk/qTt8n7ZbcBRhb5Fmz7NYB9TOx0RZZeNhMlcx+jQlILrKQWaGzE4flFeFToNFSirmn/dBE7bIPyf7pzg/dG7fgLfdy2j7eSk8Bf9qnj755brdM+2pU8pE+jCjF82ropgTUOLKsah6y25l4WwASrrayEnTOKFGjsKhzLLRT0UaiDPYis4SFTFJ2XxvoCHnyU98WRm6pWgMAcqOkrB/Ze5sC8KczCjPqAx7MPiHuhJPW2DCqqfi9E8qXT9o6UPSUswKjpWKOYmTIsgXlzmCgKC86xyZxdnl+wCUyNBTYTUks9Y8I/SjM0foXIc9No3Ae0BQeY1S+P3KVw7sHY4ooUXp5f/N8g19bkAAWhRsO8/X5N3RmwL197+ZcCvwbssT89+zQ8LA3/n8XUATZ1lptic054OramPjUF7IuMLJVaUt1Y4ZoaG0PocaL46mHqOfMWMxr6jHZ7QURh8cXoSMluZLmSoJG50jSqiMgWKowD56hYCl2wQrpaiXlEXwcKPCLmcgtANSjafLDvkztxGItGm9+P6enH9PRjevqrp6doPBp1+DcxSQ37516Yvt1uG41Io0i/z2kqHihGXfAdDB/ddDEO9dscQpL1J51RoN/jk5FvL96DGZqv8OyTHl9k2Y1XMfpaPbzzW74HDjqWb+TiV2TbJsXlKam3feitz5pakLHy93Du8ubozZ/9/vI53vtW3l6+LLDDcQze0Svd6Mh7GEmSKJjR7Or96U//OvqJvWIOgNHX/ZqDbQy4MMjem0aH8L9+/bd6fd1VkHDa9mjwexU3JVhgD8L5CctMFFTsQWLJ5qaxjBwPDg/+PuxYVlTqIDtO9pTJn3Xu9NHk9GvlZruQfXKzOB6PZtI+NZssDRsmj9VvafSAyJfUDB/H8CXy0IvrZOzuccu210s/+Th/jsveaaTbNJtidJJEXae71BMfKpF/wtNUysOtHH+FJuWHi41LNu2hqOXh/fHhmgIas/sLOv70m5eItUsPD0VdH9TWFAfLVDpAoHPMu9Xtn2tK38Csnx/wCqYWXHlqzFcZE0DU8j8w76/55OHn/hGO27Aq9MCs+7VNNi8VLfWRhby7GESfJ0Gg9Rk19bc/VhnS2c6WuZJw11T0yDT4uU9F1j13UIjBuhCD+9cHRwdHZFRtHFZCrw7JR+KzdpGjA4DwXzyslZA6uqAQYnfL020XpEQtyaJjT9Phta7SUMW65YvFRDj4bFXb0te/NUAQb++Iq1YSyXyQV/cnpkI52DBxWbD5P666hPgn48l20/sA63lIiYY+8YR/hfnWm17tHV2GAVH4S2KLTo7CXGOkYaNTEOeWVP/w7oY80r3F6A+WAweS/p+okA6tWyyChJ+X2nZpbBjB2ru2bf8AqA2eIQ== sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List connected repositories --- --- id: list-security-settings-organization-name-api-v-1-security-settings-get title: "List security settings" description: "List security settings" sidebar_label: "List security settings" hide_title: true hide_table_of_contents: true api: eJztWl9z0zgQ/yoaPd3NmLYwzHDjt1LgJhyUDi28dDIexd4kAkcy0jq5kPF3v1nJduTETdIWOGD61MZerfa3/yXviqOYWB5f80tISyNxyS4BUaqJ5cOI6wKMQKnVIOMxz6XFhqyhShJtJkLJr44sUWIGSSIKmcwfJ7amTWxDPAHkEW+e8/h6xV8v8DRNwdrnIAwYHl8Pq2HEC2HEDBCMdVTEl8d8ay8ecal4zAuBUx5xA19KaSDjMZoSIm7TKcwEj1cclwUxsGikmvCIo8ScHrwLOLJz4ljR9gZsoZUFS2ufnJzQnwxsamRBlDzml6WTelzm7H1NzCOeaoWgkMhFUeQydYyPP1laswrkKQzpFqXfIdMzIVViwIKZuyXusUSY2W3pq6h5IIwRywDNC8eHBFrzqdYKT6RCmJieDbrilKXM+pQ21mYmkMeeYL3tB/pZRV3z3JZJxxINxxmgyAT2qMyzXZHGLXHTMksDblf0uopqx7nZ/t7kpCIzB5M0+yWlyXctu3Tk7G1Nzj6YnLikuQSFST/wZu2ZI2KDLFhhITWAB6y69ITV2gf06BOk2HH+a/+uRt8PLhR2U4xhYJXBi7Mm5gdr72mAEwRpE5GinId6Hmmdg1CB/APLTj0VoTYgELJE9EJuPSQTCI9QOgytHvxSdrpfCbWDbXtl4Feh+B25hqGxt/DviME2kQ7CYAujsNC5TJcuR6jlu7FLcBv5AMaizDERea4XkJHlpjrrhqxW0Lt2MzBGwso0EaVLkN3wOMSJAj08J06nJU7f6IkkF5hq8uE7Rua3TxZBdrs1w8BYNb/DIqzPubbk2IinjvqGEc8kFZaZVAK1CTLd8txXvXqrmSgKAhGvQpvuTYzf3f7ewHdN0A9u4LRYVTuqus8G7NRnA/a2zgZRkydc0xRxly0SqUa6VFki1VziutTfmJgdVzbwq9ggWBXwp3aq3UGXeJct3tXLdu7Ro+7NxHrh0mdQgdqdVZnnvBrus1lft3VTk7SdtnsKQ9MMt42gN+fTk8d1ANylJ7QosAz16uQCE2rEk7Rw18FWGhVLNRdGCoUxGKONjSkHJOlU5DmoCfTEYv375ibkyv2tyGgo5M4O6YWncPFoUagUugVvs6XdNGIYk/V6ahxa6W9RAQm36oH7O1fXw/reW3SRgaQX5SiX6UPp+hE63lUXNuvBgVttun2wK2lInQUZonvmvZoCKy0YNistssLoucyACVYYORNmychSoLDOcCw1kNFPkR8d4MgKFklO1rmvrc9h4ax8KI5Uz4ocEJiFfPyIaoJMgTlRmIGJtOiLwSEg5iKXdGpJYEbZ755IPtbcXhKz25gFGBUdo3OmxwynwJw4TGSZAWvZaMkuBudsBGNtgE2EVFJNmHAXGgy1WyHSVJcKDwFNhRST4v6WuxDWLrTJ6P4CLwbn3w1yYXQKkBFq1MzJ79YUtQCH+mtDf1/gl4AN9ttHn4JFK/g3s6kFLIsk1dl2n3B7bGVxpjM4FBlJKpWkvLHGNdYmhNDgRPHZwVRL5iRmdJTXyh4EEYXBe6MjJruR+bsVZqe6zLPA2XyGsWAtJUuhMpZJW+RiGbivhRwcImZTA0A5KNi8s++tK7Fvi/YWv4fu6aF7euie/u/uKWiP9ir8l+ikuvXzIEy/brUNWqS9SH/PbipsKPaq4DdoPuruYj/UX7MJiTZPOnuB/o4nI1denAYT1J9B3fWGyyVZduVY7NNEfS0YNfXI82hv5MIrsr5OMbyi3NTWB0UlSBv5FVx5f3ry9EffX95Fe7/K7eX9DNttx+AlXekGgwddSxJFxrRi71+dPfvr5Bl7xCwAo8fNmqM+DzjXyF7RHb0z/5MnP9X1dZ1BSNIdxm9YXE3BAFsI6zosPcphxhYSp2ypS8NI8WDx6Ofxjjaj7pnNyHXK7zIa8kanbqDCTnYhe2snoT1ujKRDcjZJ6jeMbsrfUquOI19QMbwZw8dAQ/fOk6G690vWny9d52OtGOXAXiqkmaZtsjfSImu+IrFmFsoPIdBBKuZ+LMrNMMX8eLU15VQdi0Iezx8fN1weBVz8cIcfk3JTK3yKWNj4+FgUxVFhdHbUhtIRQjp1DthwuqTw9Z71eoHvYWzATs+0/ixDBxCF/AeWzbBV6l83Rzhu/CpfA5P6bRVtj3a1/EhCXo9n0e+RJ6hcRI21o2wjpJadtbEScVvO6MjUed2EIqvPHWRiMNbbYP7k6OTohIQqtMWZcKmrFv9G+3TM2MqO8C8eF7mQbgiknhPytrvmcd+EmigkCfM4+Ji4NuAw4lNNGeuar1YjYeGDyauKHn8pgSBeD8lXjSQnc0bOpHO4jMdjkVvYkrNN2PyP93VA/Ml41C9/Y2C19CFR0i8e8c+w7J23q+hD8xRE5kb1VjUdmbnAgMNWpSCfa/3975dXpJb6FqP5bOx9IGr+CRJpV7rVylO4fqmqWmF9C0aff6v/ALjgQEc= sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List security settings --- --- id: list-tokens-organization-name-api-v-1-tokens-get title: "List API Tokens" description: "List API Tokens" sidebar_label: "List API Tokens" hide_title: true hide_table_of_contents: true api: eJztWllv2zgQ/isEn3YB1U6KAl3oLU3TRbptNsjRlyAwaGlssZFIlhzF6xr674uhjlDxmWS3bYo+JZKGM/PNTdILjmLqeHzFD06P2YW+AeX4dcS1AStQanWc8pjn0mH9bTTSdiqU/Oo/jpQoYDQSRo5u90dYU0wBecQdJKWVOOfx1YK/n+FBkoBzb0BYsDy+uq6uI26EFQUgWOepiBmP+ZIAHnGpeMyNwIxH3MKXUlpIeYy2hIi7JINC8HjBcW6IgUMr1ZRHHCXm9OLvgCM7IY4VibfgjFYOHK19ubdHf1JwiZWGKHnMz0uv9aTM2VlDzCOeaIWgkMiFMblMPOPhZ0drFoE+xpIZUdYSyEq1iehJIhRumagsZboKykTbQiCPa4I7aJf0WEV9oz2USc8+LcfSgX0wp0sHtuNQAIpU4ApT1J5ecKHmf0+87/sCqqh7o8o85+StVkTtP/JCUbReeASbw2Z5VUUtjR5/hgR7EXbFmwBspQUcDk6PfU58bGGSUhYEQjoSuNFqqUB4gdJz7hSql7IDJEYp5HDHaB3AlSw3oX5bs/VCtgBvPLscWGFoBE7ugV9hJn4nT1gr5gH0AyPb0rNNqyCJVsgIkrSfyB+kQ6YnrCUkQSTq1d4+2feRGe1QYOkCT0uFMAUbQDuvSTpUXpbzmWNVLNWtsFIojMFabV0sSsxGSSbyHNQ0jI4LWl11z+tr3YX/6yMIhcw3kb6tKSoqrw6FSh6dk8ftekqBTvt4wbWChlnfcveNQbjVCrgiz/UM0lEBmOm0Xzh35T0WTiYjkrAkYEuw+W8BzDfE6aDE7IOeSsr7TKfeLpsV0DJNVmBri+A69zSNagcVG16BpqflOJeJ91EqKREKqQRqG8Tw/KRutw2HQhhD8uNFaLClkP/mxq2tt1WP72jjqtpQ2er4ZR+b+N1R1P2wD0sdZcphUCH6he4iA0blmRWlQ2asvpUpMMGMlYWwc0aeAoVNhWOJhZQeRT7YIZAVzEY5eeepvj6BmffyrjgSXRhqXMxBPnnhwN7KBJhXhVmYSof1sLoLiFuRS2qWIyio+j0RyaeG2xExe4hbgFHTsTqntoQZMK8OE2lqwTk2nrPT4xM2hom2wKZCKqmmTPhxlKH2K0SS6FLhLqAtOMCRebrnToVzM23TM2J4enzyv0E2VicAKaFGzbz+fo1pFNg1Xlv6pwI/B2yxPzz7FMw6xf8znzrA0owSnS7PCQ/HVppDncKuyEhTqSTVjTtcE21DCC1OFDceppozrzETCfF0O0FEYfHJ6IjJZmRJLkEhc5ku8zQItrrCOHCOiqVQKUulM7mYB+HrIAePiLnEAlANCrcZodwHd+J6LNra/H5NT7+mp1/T0/eenoLxaKvBn8Uk1e+fO2F6vt02GJG2Iv05p6lwoNhqgp9g+Gimi+1Qn+cQEt3f6WwF+jPujHx78Rasjw0fe8LliyxrDjK3WKI5FozaflTz6E7kwiOyVZNid4jpde9b61JRC9JWfgXf3l/tvfrW55ePsd5zOb18mmP74xgc0ZHu2hNpokiZVuzs3eHrP/ZesxfMATB63a4ZrIqAE43snS5V7f6XL3+o4+umgpCmG5zfsrjIwAKbCecnLD3OoWAziRmb69IyMjw4HPw40dFVVOogG+7wcp30vt6XtW7c/aATf23mppuQfXTT0B9rM2mXmk2a1gKjdfVbatUL5FNqhusxfAos9OQ6GZp7u2ar66WffJwT4xzYkUK6kV4m89dDwQW4v9aiHVTM69tsf/Uc8+Fi6XK6Ggojh7f7Q2yX0lDdXmmXNucxzxCNi4dDYczAWJ0OusQZICSZD7f2vvyckrWOo/czPIOJBZcdan0jQ3cLI/+CeXsxntSf2w0bt/WquuONmq9VtHwN3/EjDXlzlU7P45qg8vkz0Z6yy4dGd9ZlRsRdWdAGqfe5TTzW7DLIoWBdbfHbl4O9wR4pZbTDQqi7a+EV3uh5q1Ma4R8cmlxIf7foTb1oPHXF41U/IxBGkhb7FGzdJWKmqRpd8cViLBxc2ryq6PWXEgjQ1TXFoZUUQN6lqfTBlPJ4InIHS8p1xZj/dtYE+++MR6uVbt2p5nW4l/TEI34D85W/hKiuq4hnIFL/I4pFQ0dONRhwWOoCFGFdSP95dEG2aE4oGhUaj0ftP0GR7Gu3WNQU3jlV1Slbj1fVdVVV/wIUZ+ch sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; List API Tokens --- --- id: logout-organization-name-api-v-1-logout-post title: "Log out" description: "Immediately terminate the current session. This invalidates the access token and cookie. API tokens are not affected." sidebar_label: "Log out" hide_title: true hide_table_of_contents: true api: eJztWU1z2zYQ/SsYnNoZVrI9OfHmpjk4dRyNreSi8XAgckUiJgEEWEpVNPzvnQVBmbQsS67b5mNykkgAi327b7FL7IajyB2PZ/y8xgIUylSg1IrfRjwDl1pp/GPML6oKMikQyjVDsJVUAoFhASytrQWFzIFzUqsRmxbSMamWopSZQHB+lkhTcI6hvgPFhMpYqvWdhBE7n1y0bx0TFpjSyMRiASlCNuIR1wasV+ki4zEvda5rTBJtc6HkFz+QKFFBkggjk+VpEmYY7ZBH3EFaW4lrHs82/O0Kz70Wv4OwYHk8u21uI26EFRUgWOdnkTQe850deMQlGcIILHjELXyupYWMx2hriLhLC6gEjzcc14YEOLRS5TziKLGkF+97EtkVSWxoewvOaOXA0dqzk1f0MzT9pc5zyJiuMeqMfO+CjDcRf3VySstSrRAU0l9hTBl8Of7kSMymp6KxZFaU7aYOBdaup7pUCDnYnu437ZQmClP8Xg55zGurYvK1lUJhDNZq62JRY5GkhShLUDn05ExpdbN93m+sqf9tiIUoZPnU1D/aGQ35x6FQqRcs1Pr9wjt0uK6Jtm9UXZacXNBJuujWNxG/1z7ecK0gCBta7qExCLd6BK4oS72CLKkAC535pRKhcs+RPRdOpgntsLPB1i1czz9BigN6ztqxHszfSRLF+6XOpXrndfJ2eVoBLbP0EWxtvOx3T2D6ESoGWT1NJ/W8lKn3USYpJDznte1xeH3VxmuQUAljaP940zfYDuX/d+O21juox1e0cdNbL6wV657885a/7F3g75FbPaR9b1eykHrdOyGGR960AFY7sKyqHTJj9VJmwAQzVlbCrpkYZCuWWsjoUZSjI4isYEVpQu5G6jN9fQUr7+VjcaS6MiUgMAfl4jcHdilTYF4VZiGXDttUdwyILrsmUNHp90IkH4O0NyTsOW4BRknH6pLphc/zXh0mssxSup+v2eTiis1hoS2wXEglVX5fC3SVga4VHgPaggNMzMs9NxHOrbTNrkng5OLqP4NsrE4BMkKNmnn9/RoTFDiWr938lwK/AeywPz/6FKy2iv9rPnWAtUlSne3WCc/HVpvXOoNjkZGmUkk6N+5xLbTtQ+hworjzMNWaeY2ZSEmmOwoiCosvRkdCnkaWltIX4oWuy6xHtvaE6UpHKr4z6Uwp1j36OijBI2IutQB0BvU2H+z77EzclkUHk9/P6uln9fSzevra1VOvPDpo8O+ikhrmz6Mwfb/ZtlciHUT6Y1ZT/YLioAl+gOIjVBeHoX6fRUj08EvnINAf8cvIpxdvwcTflf7TGy5/yLKpF3HIEuFaMOryUStjeyPXvyJ7rFK8Dvea3Os+tNYHRSlIW/kl3F+enX1T95eBQqTsE3eXnYhpARbYSjifYvW8hIqtJBZsrWvLyKTgcPQtXW7e4xtW00O7ljodjD7ca1+9c6lTGq1c/hSydy7v+2PvRfAxQUuathtG+wJYavWGnNvRckKn4X4MH3sWenGg9M19WLPHA8anPufEvAT2RiH1NGhaWxxSW6JtePjuRMzHm53+RTMWRo6Xp+O2Q+KbI3bZdT1qW/KYF4jGxeOxMGZkrM5G28gYIaSF51PXUrmhaGyJ8naF17Cw4IrXvqnT86cw8k9Yd72TtufTldFUgfhV7ZmWhNEm2u3UbOWRhjx0W+h53k5ofIAstJ+5JXzQnW2pH3FXV1QCD4a7yGKhjiSPgXWt5Zdno5PRCSlFFq6EP4mC+pc6Z60pB97qHWRfrW0WzIXwF45NKaQiBN7Jm8CRGY8f63EJIwn/KY9Cs40YWxC54hnfbObCwQdbNg29/lwDmXJ2SxS3krjpyZRJz9OMxwtROnjCPL9chzj6le1TuiOSWreRVNMTj/gdrB9t0zW3TcQLEJnv8G3CPKKTwZ6EnQRD3N5G0+T9zZSMET5/gw6BbFH3p3cAD9XbbNoZPtE2zVbbNnc3t03T/A0YD0bt sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Immediately terminate the current session. This invalidates the access token and cookie. API tokens are not affected. --- --- id: modify-monitor-target-organization-name-api-v-1-monitor-targets-monitor-target-uuid-post title: "Modify Repository Monitors" description: "Modify a repository monitor." sidebar_label: "Modify Repository Monitors" hide_title: true hide_table_of_contents: true api: eJztWktv2zgQ/isET7uAaidBgS50a7MpkG6bBo7TS2AItDS22UgkS1J2XUP/fTGkZFN+J9ltm6InW+JwON+8OORoQS0bGxrf0R4oabiVek4+SIF/DB1ENAOTaq4sl4LG9IPM+GhOGNEr6sJTd2hEpQLNkPQyozEtHHHNrM/0GGySSD1mgn9zVIlgBSQJUzyZniY1n8Q6SpOsvUjKkmdJoqSxNKIG0lJzO6fx3YK+m9nXaQrGvAGmQdP4blANIqqYZgVY0MZR4WJOqg2uNKIc0SlmJzSiGr6UXENGY6tLiKhJJ1AwGi+onStkYazmYkwjOpK6YJbGtOZiuc3BqcmtQTxocoujVRUtZdhQwqMlaFb8GHAkV8ixQhUgIzD2jczmOHudbyqFBWFxiCmV89TN7342aOxFsKzSaFrLweCTR7FbGL8+si+Kmv0u0vOapEJZG5dKSp3vmxS46q3OcW5jVKe/PTMbw1wjXRVRAXYm9X1yEJGnazQbNYRy+BlS27LYHa0N2qDfQLYm7poUg0A5GpiFVgD1vEFpVVVOZUZJYbxVzk5e4k87YG9KFxijMie9mhhxvzw5RdpH2t9YZksT6IsLC2PQgcJuPMlSU24t40JFi5iLKdOcCRuD1lKbmJV2kqQTlucgxhDw6ePsavm820J991thwrKM73Wfvz1FhTFnLBOpY8zE/OPIJYr2PAzb+o0o85xWgYEum/no7Evp4wWVAmpmbc2tKwNxiy1wWZ7LGWRJAXYiMzeVWyjMQ3gPmeFpgitsLHDAgd1YAPMNcnpd2sl7Oebig5PJ6WW/AJJn6RZsx2WPY0SseQWSXpfDnKfORhnHOCi4YFbqwIfnVz4H1xwKphSuHy9ChW24/HdXrtfeQTl+oI6rYD7Tms0D/q+9/5IPtf8eudS62weroobEeZAh2nmuPwFSGtCkKI0lSsspz4AwojQvmJ4TtBQIW2c4kmrI8JHlnSMcWcAsydE6T7X1FcyclY/FkcpC5WCBGMhHLwzoKU+BOFGIhjE31pdbx4CYspxnzEICBWa/JyL5VHO7QGYPMQsQ3HS0zIkcETsB4sQhLMs0GEOGc3J9eUWGMJIayJhxwcWYMLeJESvdDJamshT2GNAaDNhEPd1y18yYmdRZDxleX179b5CVlilAhqitJE5+N0fVAhzrrw39U4HfgG2wPzz6BMyWgv9nNjVgS5WkMtusEx6OrVTnMoNjkaGkXHDMGytcI6lDCA1Oy+4dTDEnTmLCUuRpjoJombZPRodM9iNLcw7CEjORZZ4FzuYzjAFjMFkykZGMG5WzeeC+BnJwiIhJNQDmoLB0Ddd98E7sy6KDm9/v6ul39fS7evrR1VNQHh1U+LOopNr751GYnu9uG5RIB5H+mtVUWFAcVMEvUHzU1cVhqM+zCInWTzoHgf6KJyO3vTgNJlbeg3jsDZdLsqTvWBzSRH0tGDX7keexvJELr8i2VYqr+8mqWtfWrcAtSGr+DTJ/f/nye99fPkZ7z+X28mmGbZdjcIFXuktjrlsSKTIiBem9PX/118kr8oIYAIKvmzmdbR5wJS15K0vhzX929lNdX9cZBCXdY/yGRX8CGsiMGVdhyWEOBZlxOyFzWWpSt2w6P493LDMq7iCtw1Rbr7lMW6Pra+0qd9/L1PVwzHhv68aMQ3vsjKRjcjZK6heMduVvLkXLka9xM9yN4VOgoSfnyVDdhyXbni9d5WMMG+ZALoTFVimS+bMBdhp9H9U3zGh3sdGSrLpM8e70tLvWl+0utnRQK9eS1dOm1+oaeHRirTJxt8uU6igts84ycDoW0olzt6aRe4PB6v3o3cz2YKTBTM6lvOehuZni/8C86Zamfrg5sFHtZ/kdL6lHq2izP7zkhxLSur+Kz0NPgJrCLNJbtU8vvjI8QazanyvXW7Y5V6/We5mrkXancvW+3YkMgoaLkXQSL+Oy1iFZRmhETVngQa013CQAUp920LFAG+8g07POSecE+aMjFEwEwOom/7YPAtb8LEjBhz4NqBVu4avtqpxxgWvXfV6vizsab+uLM8VR8tNAd7Un0ojG27r5g4hO0LvjO7pYDJmBW51XFb7+UgIq6W6AMaY5Bodz14y7QMloPGK5gT0o/+jVgfwn2QWqcVUx96Fc4hON6D3Md3x+gGn4O4qwqeVqUEV0AixzH08sarpzv+SLvk9TDZ+NrRbF9zMwypTdSzsIctD1x5s+jeiw/jqhcCcwqtkMI4jNvMxSLfcd925BcybGJcNGK/U8MVybi6caeh3IUfMn2PvaWlksPIUrcatqqSRfNVeDqqr+BRqOQGY= sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Modify a repository monitor. --- --- id: modify-network-organization-name-api-v-1-networks-network-uuid-post title: "Modify Network" description: "Modify Network" sidebar_label: "Modify Network" hide_title: true hide_table_of_contents: true api: eJztWVFv2zgM/iuCnu4AL2mLATv4bet1QHdrV7TdXorAUGwm1mpLmiQnywL/9wMl2VWStknbu20d9pTYlj7yIymKEpfUsqmh6RU9BTuX+trQUUKlAs0sl+K4oCmtZcEni/A9y6SeMsG/ue+ZYDVkGVM8m+1nIkBk3b+saXiRZUoaSxNqIG80twuaXi3pu7l9nedgzBtgGjRNr0btKKGKaVaDBW3cKISnKY3haEK5oClVzJY0oRq+NFxDQVOrG0ioyUuoGU2X1C4UzjVWczGlCZ1IXTNLUxpQLLcVDgjEyEd83bZJL3WD6KNFd6I+RIjkFBFbJI1AYOwbWSxw9jpuLoUFYfETU6riuZs//GykwHc3YpVGx1kOBp88i7uV8fIRvq4D/F1DD8OQtk26MXL8GXK7YoUrGozUIY4iBA3MQjD1uedL2xYBNRglhfFKH+y9xJ8CTK65Qp40pReNi5RJU5HzMBgVf7m3j2MfaR5jmW1MxJoLC1PQEe0LP6Qn7WQZF0JapFzMmOZM2BS0ltqkrLFllpesqkBMIcK5xNlt/3y3nS/db5vQAizj1X1D//YjWgxJY5nIHTATiw8Tt3JW52FUhzeiqSraRq457uZjLPTap0sqBQSwVcutGwN5i1vosqqScyiyGmwpCzeVW6jNQ7DHzPA8QwkbArbEovsW0XyDSK8bW76XUy5OnE7OLvcrIHmR38Jtt8W1i4oBK9L0rBlXPHc+Kjiug5oLZqWOYnhx6lNUQKiZUig/XcYG2wj5725cb72tevxAG7fRfKY1W0T4r338kpMQvzuKWg/7SCpaSBxGGWI1z12WQBoDmtSNsURpOeMFEEaU5jXTC4KeAmFDhiO5hgIfWTXYIZAFzLMKvfNUX5/C3Hl5Vx65rFUFFoiBavLCgJ7xHIhThWiYcmN9rbELiRmreMEsZFBj9nsik08B7QjBHuIWILjpaFkROSG2BOLUIawoNBhDxgtydnxKxjCRGsiUccHFlDC3iREr3QyW57IRdhfSGgzYTD3dc2fMmLnUxTkCnh2f/m+UlZY5QIGsrSROfzdHBQV2jddu/FOJX4DtuD989QmY94r/Zz41YBuV5bLYrBMezq1Rh7KAXZmhplxwzBs3vCZSxxQ6npZdO5piQZzGhOWIaXaiaJm2T2aHIPczyysOwhJTyqYqomDzGcaAMZgsmShIwY2q2CIKXwMVOEbE5BoAc1BctMZyH7wT+7Jo6+b3u3r6XT39rp5+dPUUlUdbDf4sKqnV/XMnTs93t41KpK1Mf81qKi4otprgFyg+QnWxnerzLEKS9ZPOVqK/4snIbS/OgpmV1yAee8Plkiy5dBDbLBGuBZNuP/IY/Y1cfEV2W6V4cz/ZtuvW+ihwC5Kaf4PC31++/N73l4+x3nO5vXyaY1fLMTjCK93emeuexBEFkYKcvz189dfeK/KCGACCr7s5g9si4FRa8lY2wrv/4OCnur4OGQQ1vcf5HcRlCRrInBlXYclxBTWZc1uShWw0CR2Nwc8THX1GxR1k5TC1atdK5itf12XdVe6+lzl+rc30PmYnZhr7486VtEvORk29wOSu/M2lWAnkM9wM7+bwKbLQk/NkbO7tmt2eL13lYwwbV0COhMXe4eawE9eeJKG3hCbxB6iUhr6ja9eldLjcaOi1Q6b4cLY/7DqXw2Xcamxd01LPum5koyua0tJaZdLhkCk1UFoWg34lDSzkpYu/rtV5gavXB9a7uT2HiQZTHkp5zWP/M8X/gUXXXcz95+4ER7Wf5bfALHxtk80Oao+HGtLQj8TnsR+ApsO0cn7Tbjz6yvBIcdMuvInFvi0YxT4XE+nk9MsrMCf9QkuoaWo8b6187tYxCYcWjA/QxjtwdjDYG+whPjqsZiJSZ8O5K77vGVv4aoeqYlwgjPPTMvj9iqa3NXKZ4qjEPtq563wnNF3pNI8SWmIIpVd0uRwzAx911bb4+ksDyPBqhHGuOQaoi5CCu2AtaDphlYENdftkT/84D4vpT0KT22l00SEWfjk1+EQTeg2L9Z445sDvKHvToO2oTWgJrHCt/GUYd+hFvrj0OaLD2djnUH0/AyNa2XvHjqIVfvbh4pImdBw657U7/lDN5pit2NzrLFWf9N27Ja2YmDYMu5zUY+LS6G59AvWwaJLuT7TxrFplufQjXH3Ztr2RfMnajtq2/Rd1mZw7 sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Modify Network --- --- id: modify-notification-group-organization-name-api-v-1-notification-groups-notification-group-uuid-post title: "Modify Notification Group" description: "Modify Notification Group" sidebar_label: "Modify Notification Group" hide_title: true hide_table_of_contents: true api: eJztWt1v2zYQ/1cIPm2AaidBgQ56a7N0SLe4QeL2xTAEWjpbbCSSJSl7rqH/fThSkuVvJ+7apuhTIup0n787HnleUMsmhoYD2pOWj3nMLJfC0GFApQLtnq4TGtJcJnw8bxP9pWWhokjqCRP8i1uKBMshipji0fQ8Ei3iaILUJtqyGBUFT6JISWNpQA3EheZ2TsPBgr6b2ddxDMa8AaZB03AwLIcBVUyzHCxo46hQKA3pDs40oFzQkCpmUxpQDZ8LriGhodUFBNTEKeSMhgtq5wrZGKu5mNCAjqXOmaUhrbhYbjMkaPuAOCeQD0hRlkGjy4ZTnqxFLfV9iyPpIccSXYGMwNg3Mpnj1+t8YyksCIuvmFJZpXX3k5EC15ZilcZwWw4Gn7wVu5Xx8pF9nlfsd5FeViRlQCFnPIss0xOwTgwT8/djF0JuITebbMqgXmBaszlFD1cLosgyih6oBV0hd9KvuJcBFWBnUj9EphiZWHPlgf21xfa8FHK/IqVcspCjTxDblZgPaAWJ2n/rvtmlfEvupQZmYSMf7zweaFmiChqMksL4oF6cvcQ/CTQMaUjvC5df4yIjdxUxmv/y7BxpnwgfY5kt2n7lwsIEdAsW956kcZOTZVy2aRFyMWWaM2FD0FpqE7LCplGcsiwDMYEWnz5+XTbPu3HYd3/LgCZgGc/2kf7pKUpMWWOZiGEVNetg2Q2O6/p7zJVG+3BBpYCK2arn1p2Bdost5rIskzNIohxsKhP3aYPlY3mPmOFxhBI2BBxAr3vXMvMNcnpd2PQfOeHixunk/LJfAcmTeIttxxWfY1SseLU0vS1GGY9djBKOeZBzwazULQzPe76EVxxyphTKDxdth21A/ps713vvoB7f0cdluV5HlzSvPX7JTYXfI0Wtw74lFT0kLlsVYrXO9VMghQFN8sJYorSc8gQII0rznOk5wUiBsPW2HmtI8JFlnSOALGAWZRidU2Pdg5mL8rF2xDJXGVggBrLxCwN6ymMgThWiYcKN9R3cMUZMWcYTZiFyW9GplnysuLld+TFhAYKbjpYZkWNiUyBOHcKSRIMxZDQnt9c9MoKx1EAmjAsuJoS5TYxY6b5gcSwLYY8xWoMBG6nTI3fLjJlJndwhw9vr3v9mstIyBkjQaiuJ0999oyoFjsVrTX+q4fdga9sfn30CZo3iXy2mBmyholgmm33C420r1KVM4FjLUFMuONaNpV1jqdsm1HZa9uDMFHPiNCYsdk3eUSZapu3J1iGT/ZbFGQdhiUllkSUtsPkKY8AYLJZMJCThRmVs3oKvgQycRcTEGgBrULt9bct99E7s26KDm9+v7ulX9/Sre/re3VOrPTro8GfRSa3un0fZ9Hx321aLdNDSn7ObajcUB13wEzQfVXdx2NTn2YQE6yedg4b+jCcjt704D0ZWPoB46g2XK7Kk71gc8kR1LRjU+5Hn0dzIta/ItnWKy/vJslz31geBW5DU/Ask/v7y5be+v3yK957L7eVpgV1tx+AKr3SbYK5HEikSIgW5e3v56o+zV+QFMQAEl+tvOtsQ0JOWvJWF8OG/uPihrq+rCoKa7gl+zaKfggYyY8Z1WHKUQU5m3KZkLgtNqolP58dBR1NR6wFLc5ha9Wsm45W3+4cu7RoT49vcTPZZdmMm7XjszKRjajZq6gUGu+o3l2IFyLe4Ge624WPLQyfXyba7D2u2vV66zscYNsqAXAmLE9dNshs39CWbE0/0jj9LhbQa3LrJZki7i43ZZ9llinen590tA+HuYsfYtnSzYD2th7yFzmhIU2uVCbtdplRHaZl0mlTrWIhTB9B6gnyP6e2R925m72CswaSXUj7wNkCY4n/DvB7Pxv51fcSj2n/l98ioelsGm4Pphh9qSKuBLj6PPAH6FuvO3XJee/UvwzPHct66BGszV10urQ1PB/Wb4c5B55LEZftYOi2b7K38Rpo8DqgpcjzOrbyuywSpzkQIP9DG42N60TnrnKFDEAQ5Ey1j9mFnBWWN6yz8a7sqY1wgRxfwRQWrAQ23jdSZ4qjPOQZsE1s0oOGuHwUMA5oibsMBXSxGzMAHnZUlLn8uAF0wGGKeaY4J4gCYcJcsCQ3HLDOwYUSz2dDf7qpk/p3QYLtxNfjE3KdzgU80oA8w3/NLBizH31CNTY+XCKUUWOJ+i7Go6C69yBd9X65qPhtbLqrvv8DcUXYv7bBVYW7f3/dpQEfVjxxydxKjms2wcLKZ11kuB/xubUEzJiYFw4Er9TwxCesLqMr0Kj2D+p/WHrjqlcXCU7hWtywbJ/nuuRyWZfkfx75QiQ== sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Modify Notification Group --- --- id: modify-security-integration-organization-name-api-v-1-security-integrations-integration-uuid-post title: "Modify security integration" description: "Modify a security integration. This is used to modify an OIDC integration." sidebar_label: "Modify security integration" hide_title: true hide_table_of_contents: true api: eJztWt1v0zoU/1csP90rhXZDSFzlDQpI48KYtsHLVEVufNoYEjvYzkqp8r9fHdvJ3I+13QZcQDy1iY+Pz+98+dgnS2rZzND0il5A3mhhF+QCrBVyZug4oRxMrkVthZI0pW8VF9MFYcR0tEJamGmG4wNyWQhDhCGNAU6sIlUgl+TdyYvRCi1NqKrBP5xwmlJP28lwckOaZUrPmBRf/ZNkFWQZq0V2fZx1YmQRa5PFT1nTCJ5ltTKWJrSjp+nVkr6e22d5DsY8B6ZB0/Rq3I4TWjPNKrCgjaPC9WhK11nShArUSM1sQROq4XMjNHCaWt1AQk1eQMVouqR2UeN8Y7WQM5rQqdIVszSlgYsVtkSCCDF5j0Ntm/Srb2jg3st3y72LOJJT5NgieGQExj5XfIGz1/nmSlqQFodYXZcid/OHHw16xzJattZoXSvA4FMFlnFmt4x48ZbI2KBSlOB5JOUlDrdJUMPtaDwAtK++Bp1162WNLndNu3Dk5G0gJ+91iVzyUoC0meC75o4cETnh0QwDuQZ7wKwLT9i2SUepJh8htyumvPJjAf12cLGw62KMI2ufvBhtCa0O+F5BegNGPEcamIUtXM+9D9G2RbYaTK2k8eZ+fPQEf1aTykXjonDalOQ8EKNOnxwdB8+4j8sZy2wTuZgPYNCx9T1JD/3GCxstUyGvmRZM2hS0VtqkrLFFlhesLEHOYIuThufbjX/pfltMqpaJnZ75wlO0GObGMpk7xkwu3k1dVlqdh5kivJFNWdJ2HOeVMB/dtJc+XVIlITDbHZKIW26By8pSzYGjPxaKu6nCQmXuwnvCjMgzXGFjgUNCI4L5HDk9a2zxRs0EOnahuNPLd8w3d4jeSNKzZlKK3NmIC4yDSkhmlY58eHHq037gULG6xvXTZaywvbn0uyvXa+/75vSH6biN5jOt2SLi/8z7L3kb/PfApdbdPloVNSRHUYZYzXOXBWBlpEnVGEtqra4FB8JIrUXF9IKgpUDakOFIroHjIysHBziyhHlWonUeautTmDsrH4ojV1VdggVioJw+wj1K5ECcKETDTBjbVXz7QVyzUnBmIYMKs98DkXwI3F4is7uYBQhuOlqVRE2JLYA4cQjjXIMxZLIgZyenZAJTpYHMmJBCzghzmxhWvTiD5blqpD0EtAYDNqsfbrkzZsxcaX6ODM9OTr8b5FqrHIAjaquIk9/NqYMAh/prR/9Q4BdgO+x3jz4J817wb2ZTA7aps1zxzTrh7tiaeqQ4HIoMJRVSYN64wTVVOobQ4bTsk4MpF8RJTFjuTlAHQbRM2wejQya7kfmalphCNSWPnM1nGAPGYLJkkhMuTF2yReS+BkpwiIjJNQDmoLiAjde9807sy6K9m9+f6ulP9fSnevq/q6eoPNqr8F+iklrdPw/C9OvutlGJtBfp71lNxQXFXhX8BsVHqC72Q/01i5Bk/aSzF+jveDJy24vTYGbVJ5D3veFySZZcOhb7NBGuBZNuP/I8+hu5+IpsW6V4cz/Ztuvaei9xC1JafAXu7y+f/Oj7y/to71e5vXyYYVfLMXiJV7q9MdctiRScKEnOX42e/nP0lDwiBoDg627OYJsHnCpLXqlGevM/fvxTXV+HDIKS7jB+x+KyAA1kzoyrsNSkhIrMhS3IQjWahC7R4Ofxjj6j4g6ycpha1Wup8pXR9bVuK3ffqBxHKzPbheytmcX2uDWSDsnZKKlfMLktfwslVxz5DDfD2zF8iDT04DwZq3u/ZNvzpat8jGGTEshLabEvi2T+bIDNTd+0dT3OlA6XG13QdshqMbw+HnZ93UdxH3i4XG/atn0Xzfd2XXuQFtbWJh0OWV0Paq34oI+dgYW8cB7XLXCB8epd6fXcnsNUgylGSn0SscVZLf6FRdejzf1wd2aj2s/ym14WRttksx/d80MJaejq4vPEE6CyMJGc3zRtX35heIhYb7qGlXtP3NonvRmOGqAbL7seZx8zLo6nyonbx2VQIOkjNKGmqfCgtjLcJQASTjvoWKCNd5Drx4OjwRFqBh2hYjJCEj5E2PYZwno6j3Lwt/1+IRjHwhc7rEsmJIoaOs7eZ69ouq1zz2qBQI+jDxJWHJcmNN343mCc0ALjIb2iy+WEGXivy7bF158bQLVejTEqtcBwct7NhQstTtMpKw3sUMtf5yH0/ya34eo8Wy588Df4RBP6CRbbvo7ArP0D19/UcjtuE1oA4+7DjmWgG/klH136rNbx2diZUXw/AyOytjtpx1HKOnt3cUkTOgnfT1TuwEY1m2N+ZXMvs6r7bcq9W9KSyVnDsC9LPU+Mqu6eKkAPQZ90f6KtclUry6WncBVx2/ZK8kV2O27b9j+VnIjs sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Modify a security integration. This is used to modify an OIDC integration. --- --- id: refresh-integration-organization-name-api-v-1-integrations-integration-uuid-refresh-post title: "Refresh integration" description: "Refresh integration" sidebar_label: "Refresh integration" hide_title: true hide_table_of_contents: true api: eJztWd1v2zYQ/1cIPm2AaidBgQ56a7MWSNemQZL2JQgEWjpbbCSSJU/2PEP/+3AU5dAfiZ1ma5uiT7ak49397otH3oKjmDieXvFjrRTkCAU7B6OdRG0lOH6dcG3ACpRanRQ85RbGFlx5ohAm3ess03YilPyne1KihiwTRmbTw0zekrksfsqaRhZZFrhlRjvkCXeQN1binKdXC/52hi/zHJx7BcKC5enVdXudcCOsqAHBOk9F4njK11nzhEvFU24EljzhFr400kLBU7QNJNzlJdSCpwuOc0PrHVqpJjzhY21rgTzlgQtKrIggAsw+0qe2TZbSNwzw1eJ7cR8ijuyUOLYE3oIzWjlwtPbo4Dn9FOByKw1R8pRfNN5m46Zi54GYtwl/fnBItLlWCArprzCmkrkXMPzsaO0i0stYcjvKTpJDgY2L9PXmBhspfNGRtEkg8bKcN6RVqVRTYaVQmIK12rpUNFhmeSmqCtQEIj6XtLpdPt9toUv/2ya8ABSyuo/0z46iJac4FCr3jIWafxj7GFpdR34Nb1RTVZzsfhsFYX2b8Fvt0wXXCgKzVcutG4Nwqy1wRVXpGRRZDVjqwi+VCLV7CO+RcDLPSMKGgKVbuB59hhxXYvKq+xbBfEWcXjZYvtMTqd57nbxd7ldAyyLfgq1LkrvdE8J7DxUDr0jTs2ZUydz7qJCUB7VUArWNYnh+2iVp4FALY0h+uogNthHy39y4nfV26vEdbdxG64W1Yh7xf9nFL3sf4ndPUethH0klC6njqEKs1rnLEljjwLK6cciM1VNZABPMWFkLO2fkKVAYKhzLLRT0KKrBHoGsYJZV5J3H+voUZt7L++LIdW0qQGAOqvEzB3Yqc2BeFWZhIh12W9A+IKaikoVAyKCm6vdIJJ8Ct9fE7CFuAUabjtUV02OGJTCvDhNFYcE5Npqzs5NTNoKxtsAmQiqpJkz4TYyh9itEnutG4T6gLTjAzDzec2fCuZm2xTkxPDs5/d8gG6tzgIJQo2Zef7/GBAX2jdee/rHALwB77A/PPgWzpeL/mU8dYGOyXBebfcLDsTXmWBewLzLSVCpJdeMW11jbGEKPE8WNh6nmzGvMRO773r0gorD4aHTE5H5keSVBIXOlbqoiCrauwjhwjoqlUAUrpDOVmEfh66ACj4i53AJQDYqEr8h98E7ctUU7N79f3dOv7ulX9/S9u6eoPdpp8CfRSa3un3therq7bdQi7UT6c3ZTcUOx0wQ/QfMRuovdUJ9mE5Ksn3R2Av0ZT0Z+e/EWzFDfgPraGy5fZNmlZ7HLEuFaMOn3o47H8kYuviLb1ine3k+27bq1PiragrSV/0DR3V8+/9b3l19jvadye/k4x662Y/CarnSXzlz3JFEUTCt2/ub4xR8HL9gz5gAYve7XDLZFwKlG9kY3qnP/0dEPdX0dKghpeo/zexaXJVhgM+F8h6VHFdRsJrFkc91YRoYHh4MfJzqWFZV2kJXD1KpdK52vfF2XdVe7+07n9LV2k/uQvXeT2B93ZtI+NZs07QQmd9VvqdVKIJ/RZng3hk+RhR5dJ2Nz79Zse730nY9zYlQBe62QpmibZOfdvI1F4zKyS3eKSnkYw/mpVcqHi425VjsURg6nh8N4sDdcrE/f2mEY7PmZnp32w7rGVjzlJaJx6XAojBkYq4vBMr0GCHnpg7KfBF5QSnfR9naGQf1jrW9kHBTCyL9g3g/d8u5zf6zrR5bdvpiFr22yOWBc8iMNeRjT0fOoI2h9lo21p1xmTdCdLfMn4a6p6Ri18rlPTxbOIuR2sK7zy/RocDA4IKXIBbXw5Syov91nK35dKo7wNw5NJaQiXt7ci+DOK55uG1MKI0mTQ2+8W5/yhKdbZqq9W68TXlKspFd8sRgJBx9t1bb0+ksDBPzqmqLaSgpH7/pC+tAseDoWlYMNAMvSzn87D6nzO+PJdmC929W8S56GnnjCb2C+bRZMVe8byt80c3vdJrwEUfgx9iLQUfAZjDhs7GmUCcvkPPtwcUkOCxcuQYcQmkn/J6r5q+otFh2Fb+3adqlt1y22123b/gtMPSln sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Refresh integration --- --- id: refresh-organization-name-api-v-1-refresh-post title: "Get access token" description: "Get or refresh access token from refresh token (cookie or API Token)." sidebar_label: "Get access token" hide_title: true hide_table_of_contents: true api: eJztWttu2zgQ/RWCTy2g2k62QBd6a7PtIrttGiRpXwxDoKWxxUYiWZKy1zX074uhLqbia+pu23TzEkciOZw5czgzJLWklk0NDYf0ZWFTEJbHzHIp6CigCZhYc+UeQ/onWCI10TDRYFLC4hiMIVbegiATLfO2pXr1JJbylgMOeXl5Tm7w5dMeDahUoN0U5wkNaT0oiqSeMsG/uJZIsByiiCkezU6ipouSxtKAGogLze2ChsMl/Wtur6rmMzcdDYejchRQxTTLwYI2rhvKoyFdm4MGlKNtitmUBlTD54JrSGhodQEBNXEKOaPhktqFQgHGai6mNKCW2wxfvPckkguUWOL0GoySwoDBsaeDAf500bwuHH6TIiNXdWca0FgKC8Jid6ZUVvui/8ngmKWnj9IIo+XVDMYyW7j/YimMpeHpYLDS8bpqRX9OWJFVzWVQ29SOoYUWIRczpjkTNmxNCBv89UrPRvQNivAEHy6jDGjFoMjRZRfGLyumOQbRslWcyvEniG3HbcOu0NFKSM2SFuuyREnPByc1AsfBXmvEhYUpaLqG/V60QWupTcgKm0ZxyrIMxHQN6LJ93g7Wjfst0SeW8WxX1z+qHiWuAWOZiJ1gJhbvJ27RdMeVQftGFFlGSw/c82Z8GdCV9uGSSgG1sC5yd8FAu8UGc1mWyTkkUQ42lYkbyi3k5j6yx8zwOMIZ1ibYwyXX5pn5CiVhmHwrp1y8czo5XHYrIHkSb7Ctiknb3VNHkwNUrGV5ml4W44zHzkcJx7CTc8Gs1B6HFxdVTKwl5EwpnD9c+oCtUf67g1uht1ePH4hx6Y1nWrOFH7oq/pJ3NX8PnOou7b1ZESFx5kWIblq5SYEUBjTJC2OJ0nLGEyCMKM1zpheEdZI8iTUk+Miy3gFEFjCPMvTOsb6+gLnz8qF2xDJXGVggBrLJMwN6xmMgThWiYcqNrSqKQ4yYsYwnzEIEOUa/Iy35WEt7jcLu4xYgmHS0zIicEJsCceoQliQak914QS7PL8gYJlIDmTIuuJiuai43gsWxLIQ9xGgNBmykjvfcJTNmLnVyhQIvzy/+M5OVljFAglZbSZz+boyqFTiUr03/Yw2/BtvYfv/VJ2DeKv7NfGrAFiqKZbJeJ9zftkKdyQQOtQw15YJj3FjZNZHaN6Gx07JbZ6ZYEKcxYTHKNAeZaJm2R1uHQnZbFmcchCUmlUWWeGSrIowBYzBYMpGQhBuVsYVHXwMZOIuIiTUAxiBv8s68987EVVm0N/k9Vk+P1dNj9fSjqyevPNoL+IOopLr58yCbHm629UqkvZb+mtWUX1DsheAXKD7q6mK/qQ+zCAnu7nT2Gvor7oxcenEIrs4Zv+aEywXZA48gTXPeWuejSkZ7IucfkW2qFP0jyrtofRCYgqTmX8Cl9+eD3773+eXXoPdQTi+Pc2y3HIPXeKTrne13PYk9EiIFuXpz9uL3wQvyjBgAgq+bMb1NDHgj9ZgnCdIQ3f/80f3/K/dfSEveyEJUq//09Ke6vagTCGq6w/mNiJsUNJA5M67AluMMcjLnNiULWeA14+cCjO39POxoEyoWEJ29dBfXTMad1rtzbdvtvJUxtuZmusuyd2bq+2PrSjokZaOm1YTBtvTNpegQ+RJroe02fPQQOjpN+nDv12xzunSFrzFsnAF5LSxeG2O3amuIF7/VnbK7/w1pf7l2Q1z2meL92Um/vsF0F9B61lwsFzqjIU2tVSbs95lSPaVl0muXRs9CnDpCNdfW17gcK6asX163DmWK/w2L5nq6ukpvdtGrS3NX0kR1axmgwOqy9BUwDdqThxrS+kIbn8dVh9KtkIl0PVvG17qTlvsBNUWOO+BOc7O0SL2NRJeBNhX0s9PeoDdApRDinLlQVKuPXxL4nw/cjY5eSPtmXx3UOFj4x/ZVxrjLn857y9r7Qxpu+j6AKY6GnTj2VhQYBTRF3oRDulyOmYEPOitLfP25AARpOEL2ao60czRJuKNgQsMJywzssPfJVb1EnpJtWjcUEYtqkRT4RAN6C4uN3ziUozKgKbAEGTFc1v2QKMp6EtZyB7K2XSiX769vEI36XGtF01tH0/ofL7Z21dvI2EZl/OvF4O7I5bJaC2XZ9q+ato6oTW16I2ijsiz/BYtXHt0= sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Get or refresh access token from refresh token (cookie or API Token). --- --- id: reissue-invitation-organization-name-api-v-1-members-user-uuid-re-invite-post title: "Re-invite user" description: "Re-invite a user to join the organization. This will send an email to the user with a link to join." sidebar_label: "Re-invite user" hide_title: true hide_table_of_contents: true api: eJztWt1v2zYQ/1cIPm2AaidBgW16a7MWSNekQT76EgQCLZ0tNhTJkpQ919D/PhwpKVScxE6ztU2Xp0TS8e5+98E78ryijs0sTS/ouQVDDplkM6hAOnqZ0AJsbrh2XEma0hN4weWcOyCM1EjsFPmkuCSuBKLMjEn+hSHtiJyV3JIFF4JYkAVhkkDFuMAVSOxXL7grCSOCy6uO04gmVGkwnstBQVNqgFtbwwHK9W+zLJaUSVZBljHNs/luVkE1AWOzDPlndc2LLDOQBaUzrayjCbWQ14a7JU0vVvTdwr3Kc7D2NTADhqYXl81lQjUzrAIHxnoqFEJT2nOlCeVoEM1cSRNq4HPNDRQ0daaGhNq8hIrRdEXdUuNC6wyXM5rQqTIVc8gqcHHcCSTwpj/Hd02T9PLWgH613E7Oh4gjOUKODcI1YLWSFiyu3dt5iX+Grj+tvZWmtSAnLTFtEvpyZxdpcyUdRky6okxrwXMvYPzJ4tpVpJc26F3HgyTrmKttpC+XDmZgIoVPA0mTtCRelvUWNDLlcs4MZ9KlYIwyNmW1K7O8ZEKAnEHE5wxXN/3z3RY6838bDH3HuLiP9M9A0aBTrGMy94yZXH6Y+qgZrkO/tm9kLQRFu3ecDrr1TUKvtU9XVElomQ0td9MYiFveApcJoRZQZBW4UhV+KXdQ2YfwnjDL8wwlrAno3ULV5BPkbhCTF+FbBPM1cnpVu/K9mnF56HXydrlfAcWL/BZsIUnudk8b3luo2PKKND2uJ4Ln3kcFxzyouGROmSiGl0chSVsOFdMa5aer2GBrIf/NjRust1GP72jjJlrPjGHLiP+rEL/ksI3fLUXdDPtIKlpI7kc7xHCfO+uKU1VbR7RRc15gudOGV8wsCXoKpGt3OJIbKPCRidEWgSxhkQn0zmN9fQQL7+VtceSq0gIcEAti+sKCmfMciFeFGJhx60LF3QbEnAleMAeZL+iPRfKx5fYGmT3ELUCw6BgliJr6liL0F6woDFhLJktyfHBEJjBVBsiMccnljDBfxLomhOW5qqXbBrQBCy7Tj/fcMbN2oUxxggyPD47+M8jaqBygQNROEa+/X6NbBbaN147+scBPwXXYH559Eha94v+aTy24Wme5Ktb7hIdjq/W+KmBbZKgplxz3jWtcU2ViCB1Ox648TLkkXmPCcuRpt4LomHGPRodM7keWCw7SEVuqWhRRsIUdxoK1uFkyWZCCWy3YMgpfCwI8ImJzA4B7UCR8IPfBlTi0RRuL33P39Nw9PXdP37t7itqjjQZ/Ep3UsH5uhenpVtuoRdqI9OfspuKGYqMJfoLmo+0uNkN9mk1IcvOksxHoz3gy8uXFWzBz6grk195w+U2WnHkWmyzRXgsmXT0KPPobufiK7LZO8fp+smluWutcYglShn+BItxfvvzW95dfY72ncnv5OMcO2zF4g1e6vTNvehIpCqIkOXm7/9vvO7+RF8QCEHzdrRndFgFHypG3qpat+/94dv//yv37Sk4Fz533/t7eDzW8aOsHKnqP7zsWZyUYIAtmfX+tJgKqMFFbqtoQtDtYN/pxgqOvp9g/DI7SQ7sKlQ++3pR112Hnvcrxa2Vn9yE7tLPYH3cm0jYVGzUNApO7qjdXchDHx9gK3Y3hY2ShR1fJ2NybNbu9Wvq+11o2EUDeSIdTUyQLJ0McRIaRqp9HpnS8WptYNmOm+Xi+O25Hs+NVP0RtxqabJ/uprJl349baCJrS0jlt0/GYaT3SRhWjPmFGDvLSh1k3yz3FJA3x827hTmBqwJb7Sl3x2M1M879g2Q1R8/C5O6ZTE1aFPidrvzbJ+oi454ca0nbsis+TQND4vJkqT9nnQas76TMiobau8Fg8+NwlHGnPluhIMDY4ZL432hntoFJo+Ir5DapV/3o4jxa+uWFG29w3GuO3NnLwtxtrwbhEtb1nV228XND0tgk30xxB72JuhaChCU3j2ft13FwmtMQQTC/oajVhFs6NaBp8/bkGtOzFJSaC4RjBPrYK7qO5oOmUCQv3mOmXkzbbfiV3weniSi5DvtX4RBN6BcvBzwVwh/yGgtet2lw2CS2BFf4nDquWDsNau4jDWv3DHOuT/fjD6Rn6p72aa3Vogz7p/onqw1C91SpQ+ENA0/TahnNFc9k0zT8d0P22 sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Re-invite a user to join the organization. This will send an email to the user with a link to join. --- --- id: reissue-setup-link-organization-name-api-v-1-members-user-uuid-reissue-setup-link-post title: "Re-issue managed user setup link" description: "Re-issue a managed member setup link. This will send an email to the user with a link to create their account." sidebar_label: "Re-issue managed user setup link" hide_title: true hide_table_of_contents: true api: eJztWl9T2zgQ/yoaPd3NmASYztyd31qunaFXKAOhLwzjUexNrCJLqiQnl2b83W9Wko1DgIRyR0uPJ7C92t3f/tGutFlSx6aWphf03IIhR0yyKVQgHb1MaAE2N1w7riRN6SnscGtrIIxUnqwgFVRjMMSCqzURXF4NyKjklsy5EMSCLAiTBCrGBXGKuBJIjVLm3JWE+QX4PjfAHOBnbgjLc1VLN6AJVRoMQ+GHBU2pAS/9DGV94PIqy5SZMsm/epJMsgqyjGmezfayoJfNMhSX1TUvsiyuz7yyGcrOtLKOJtRCXhvuFjS9WNL3c/c6z8HaN8AMGJpeXDaXCdXMsAocGOupUBpNaceeJpSjjTRzJU2ogS81N1DQ1JkaEmrzEipG0yV1C40LrTNcTmlCJ8pUzCGrwMVxJ5DAe+Mc3zVN0slbQ/zNcls5H3scyTFybBCuAauVtGBx7f7uK/yzGg1ntbfSpBbkNBLTJqGvdveQNlfSYRClS8q0Fjz3AoafLa5d9vTSBr3seJBkHXO17enLpYMpmJ7CZ4GkSSKJl2W9BY1MuZwxw5l0KRijjE1Z7cosL5kQIKfQ4zPC1U33fLeFRv5vg9ngGBf3kf4ZKBp0inVM5p4xk4uPEx81q+vQr/GNrIWgaPeW02G7vknotfbpkioJkdmq5W4aA3HLW+AyIdQciqwCV6rCL+UOKvsQ3mNmeZ6hhDUBnVuoGn+G3K3E5EX41oP5Bjm9rl35QU25PPI6ebvcr4DiRX4LtpAkd7snhvcWKkZePU1P6rHgufdRwTEPKi6ZU6YXw4vjkKSRQ8W0Rvnpsm+wtZB/cuMG623U4zvauOmtZ8awRY//6xC/5CjG75aiboZ9TypaSB70dojVfW7UFq2qto5oo2a8wBKoDa+YWRD0FEgXdzisZQU+MjHYIpAlzDOB3nmsr49h7r28LY5cVVqAA2JBTHYsmBnPgXhViIEpty5U3m1AzJjgBXOQ+UL/WCSfIre3yOwhbgGCRccoQdTEtxqh72BFYcBaMl6Qk8NjMoaJMkCmjEsup9ht4MfYnHS9x2bQBiy4TD/ecyfM2rkyxSkyPDk8/s8ga6NygAJRO0W8/n6NjgpsG68t/WOBn4FrsT88+yTMO8X/NZ+GzjBXxXqf8HBstT5QBWyLDDXlkuO+cY1rokwfQovTsSsPUy5i481y5Gm3guiYcY9Gh0zuR5YLDtIRW6paFL1gCzuMBWtxs2SyIAW3WrBFL3wtCPCIiM0NAO5BPeErch9ciUNbtLH4vXRPL93TS/f0vbunXnu00eDPopNarZ9bYXq+1bbXIm1E+nN2U/2GYqMJfoLmI3YXm6E+zyYkuXnS2Qj0ZzwZ+fLiLZg5dQXyW2+4/CZLRp7FJkvEa8GkrUeBR3cj178iu61TvL6fbJqb1jqXWIKU4V+hCPeXr576/vJbrPdcbi8f59jVdgze4pVu58ybnkSKgihJTt8d/Pb77m9kh1gAgq/bNYPbIuBYOfJO1TK6/48X9/+v3H+g5ETw3Hnv7+//UMOLWD9Q0Xt837IYlWCAzJn1/bUaC6jCpG2hakPQ7mD9XO0HCY6unmL/sHKUXrWrUPnK15uy7jrsfFA5fq3s9D5kR3ba98edibRNxUZNg8DkrurNlVyJ4xNshe7G8KlnoUdXyb65N2t2e7X0fa+1bCyAvJUOp6ZIFk6GOIgMI1U/j0zpcLk2sWyGTPPhbG8YZ7TDZTdEbYZxRrvjW8sdnNH68ayZtXPX2gia0tI5bdPhkGk90EYVgy5zBg7y0sdbO9Q9w2wNgfR+7k5hYsCWB0pd8b6/meZ/waKdpubhc3tepyasCg1PFr82yfqsuOOHGtI4f8XncSBofAJNlKfsEiLqTrrUSKitKzwfr3xuM4/EQyZ6FIwNnpntD3YHu6gUeqBifqeK6neD+3Zs79vD66H9zb20twM+/dA/GtDB326oBeMSMXm3L2NUXdD0tjk40xwtsocZGEKLJjTtT+hvia7LhJYYsekFXS7HzMK5EU2Dr7/UgPa/uMS8MRwD3kdgwX3wFzSdMGHhHtP9chqT81dyF642+uQipGeNTzShV7BY+XUBbqhPKHjdvM1lk9ASWOF/EbGMdBj82vU4rJVLzMRubzj5eDZCR8WbvKhDTI2k/adXTlbVWy4DhT8zNE2nbTiGNJdN0/wDapAXDw== sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Re-issue a managed member setup link. This will send an email to the user with a link to create their account. --- --- id: remove-organization-member-organization-name-api-v-1-members-user-uuid-delete title: "Remove user" description: "Remove a user from the organization. If the user is managed by this organization, the user account is deleted." sidebar_label: "Remove user" hide_title: true hide_table_of_contents: true api: eJztWd1P3DgQ/1csP91J6S6gSj3ljVIq0SsU8dGXFYq8yezGJbFd29m9bZT//TR2EhwW2KXc0VL1CTYZz8xvvuOpqWVzQ+MJvTSgyTETbA4lCEuvIpqBSTVXlktBY3oGpVwAYaRCypmWJbE5EKnnTPBvDKlG5GjmHjoSbkjp+GVkuiI252ZAHN1QsjSVlbB4IoMCLGQjGlGpQDvKo4zGVDvxnwIGx1BOQSdJyDQRrIQkYYoni92kdBQmSVBKUlU8SxIvgEbUQFppblc0ntT0w9LupykY8xaYBk3jyVVzFVHFNCvBgjaOCpnTmPbcaEQ5mkYxm9OIavhacQ0Zja2uIKImzaFkNK6pXSk8aKzmYk4jOpO6ZBZZeS6W2wIJnBMu8VnTRL28NYDfLbeTE5qRnCDHBuFqMEoKAwbP7u28xj/DIDivnJVmVUHOWmLaRPT1zi7SplJYjJ24pkypgqdOwPiLwbN1oJfS6FzLvSRjma1MoC8XFuagA4XPPUkTtSROlnEW1CLmYsE0Z8LGoLXUJmaVzZM0Z0UBYg4Bnws83fS/77fQhfvbYBJYxouHSN95igadYiwTqWPMxOrTzEXN8Bz6tX0iqqKgaPeO01F3vonojfZxTaWAltnQcreNgbjFHXBZUcglZEkJNpeZO8otlOYxvKfM8DRBCWsCerdQOf0CqR3E5MS/C2C+RU77lc0/yjkXx04nZ5eHFZA8S+/A5pPkfve04b2Fii2vQNPTalrw1Pko45gHJRfMSh3E8OrEJ2nLoWRKofy4Dg22FvLPblxvvY16/EAbN8F5pjVbBfz3ffyS4zZ+txR1O+wDqWghcRBUiGGdu+haU1kZS5SWC55h71Oal0yvCHoKhG0rHEk1ZPiTFaMtAlnAMinQO0/19QksnZe3xZHKUmH3IwaK2SsDesFTIE4VomHOjfUNdxsQC1bwjFlIoMTq90Qkn1tuh8jsMW4Bgk1Hy4JIP3o4dQjLMg3G4OBxenRCpjCTGsicccHFHOcNfGmlO9FOH9uA1mDAJurpnjtlxiylzs6Q4enRyf8GWWmZAmSI2kri9HdnVKvAtvHa0T8V+DnYDvvjs0/Aslf8P/OpAVupJJXZ+pzweGyVOpAZbIsMNeWCY924wTWTOoTQ4bTs2sEUK+I0JixFnmYriJZp+2R0yORhZGnBQVhiclkVWRBsvsIYMAaLJRMZybhRBVsF4WugAIeImFQDYA0KhA/kProT+7FoY/P7PT39np5+T08/enoKxqONBn8Rk9Swf26F6eV222BE2oj015ymwoFiowl+geGjnS42Q32ZQ0h0+0tnI9Bf8cvItRdnwcTKaxDfe8Pliiy5cCw2WaK9Foy6fuR59Ddy4RXZXZPizf1k09y21qXAFiQ1/waZv798/dz3l99jvZdye/k0xw7HMTjEK93embc9iRQZkYKcvT9489fOG/KKGACCj7szo7si4ERa8l5Wwrt/b++nur5uKwhq+oDzOxYXOWggS2bchCWnBZRkyW1OVrLSBA0Pxo5+nujoKyp2kMHH1NCuhUwHb2/Lum/c/ShTfFua+UPIjs089Me9mbRNzUZNvcDovvrNpRgE8ik2w/sxfA4s9OQ6GZp7s2Z310s3+RjDpgWQQ2Fxb4Zk/tuAxrRfq7mdVEzH9drWqhkzxceL3XG7lhvX/SKtcfs4vegWbZUuaExza5WJx2Om1EhpmY36RBlZSHMXXt0W7xyT08fNh6U9g5kGkx9Iec1D9zLF/4ZVtz5L/evuA41qf8p3uKR920Try8GeH2pI24Ub/p56gsbly0w6yj7+W91JnwkRNVWJH0SD112ikfarAh0I2nhHLPZGO6MdVEpJY0vmClOrfrugRaPeLpNBbXv+PW5rKwv/2LEqGBeovvNw3UbLhMZ37TiZ4gh+F3PLhwyNaHyzfb2KaC6xBE5oXU+ZgUtdNA0+/loBWnVyhcGvOUati6uMuwjOaDxjhYEHrPTHWZthf5L7IHQxJVY+xyr8RSN6DavBkhir4jMKXrdkc9VENAeWucV23dJhSCsbcFjreZhffYK/O/x4eHGIXmmvZFot2pCPun+CrjBUsK49hRv+mqbX18+TzVXTNP8ChIBR+g== sidebar_class_name: "delete api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Remove a user from the organization. If the user is managed by this organization, the user account is deleted. --- --- id: update-organization-member-organization-name-api-v-1-members-user-uuid-post title: "Modify a user" description: "Modify user permissions and other settings." sidebar_label: "Modify a user" hide_title: true hide_table_of_contents: true api: eJztWl9v2zYQ/yoEnzZAsZ0gRTa9pVkKpGvSIHH6sMAQaOlssZFIlqTsuoa++3CkZEu2YzvN1jZFnxJLx7v73T8eeZpTy8aGhvf0zoAml0ywMeQgLB0ENAETa64sl4KG9FImfDQjBdIp0Dk3hkthCBMJkTYFTQxYy8XYdGhApQLNcOVFQkNaqIRZeK/HTPAv7vEl5EPQUSQbzyLBcogipng0OYxyR2GiCCVGRcGTKFLSWBpQA3GhuZ3R8H5O307taRyDMa+BadA0vB+Ug4AqplkOFrRxVMgaFal50YByRKWYTWlANXwquIaEhlYXEFATp5AzGs6pnSlcaKzmYkwDOpI6ZxZZeS6W2wwJnP3u8FlZBgt5a/C+Wm4tp2lEcoUcS4SLjMDY1zKZ4epVvrEUFr0azilTKuOxW9/9aNC184ZYpdFzloPBXzlYljC74Q03kSkUaDRoQ92hlBkw0dD3wpDbBWEZUAGQmIiLCbcQZVw8RBPQhns9mJi9Hzl/Vfy4sDB2CxePRJFlFCHXEq6QI7lwHMk7Lh7Ih4pjicZeCoLPimswEbMbZa27GIP2wHK08Rb5TcnnXgQ5tRgG9RI5/Aixbbn7vm3BQTuQLmu772KycFCDgU9UZHPjg4KWJfLRYJQUxvvvqHeMf9opflu4RBoVGbmpiNGGx71DpP3KGDKW2cI0YqT26VLjW0+ywOpkGZdkWoRcTJjmTNgQtJbahKywaRSnLMtAjKHBp4+ry8Xvx5Oo7/6WWOIs49k20r88hQslY5mIYVvwbI+Tan0Z0KX24ZxKARWztuVWjYG4xQa4LMvkFJIoB5vKxKenhdw8hfeQGR5HKGFNwI4QdO8aMF8jp9PCpu/kmItLp5Ozy3YFJE/iDdh8HX3cPVUF3EPFildD0+timPHY+SjhmAc5F8xK3Yjh2ZWv4xWHnCmF8sN502BrIf/Njeutt1OP72jjsrGeac1mDf6nPn7JZRW/e4paDfuGVLSQOGtUiHad66fg+5i8MJYoLSc8AcKI0jxnekbQUyBsVeFIrCHBnyzr7BHIAqZRht55rq+vYOq8vC+OWOYqAwvEQDY6MKAnPAbiVCEaxtxY35HtA2LCMo67XwQ5Vr9nIvlQcTtHZk9xCxDcdLTMiBwRmwJx6hCWJBqMIcMZub64IkMYSQ1kzLjgYkyY28SIlW4Fi2NZCLsPaA0GbKSe77lrZsxU6uQGGV5fXP1vkJWWMUCCqK0kTn+3RlUK7BuvNf1zgd+CrbE/PfsETBeK/2c+NWALFcUyWe8Tno6tUGcygX2RoaZccKwbS1wjqZsQapyWPTiYYkacxoTFyNPsBdEybZ+NDplsRxZnHIQlJpVFljSCzVcYA+486I6DCTcqY7NG+BrIwCEiJtYAWIMawltyn7wT+7Zo5+b3q3v61T396p6+d/fUaI92GvxFdFLt/XMvTC93t220SDuR/pzdVLOh2GmCn6D5qLqL3VBfZhMSrJ50dgL9GU9GbntxFoysfIDNV7F73HC5Ikv6jsUuS1TXgkG9H3keixu55hXZpk5xeT9ZlqvWuhO4BUnNv0Di7y+Pv/X95ddY76XcXj7Pse12DM7xSnfhzFVPIkVCpCA3b85O/uidkANiAAg+rtd0NkXAlbTkjSyEd//R0Q91fV1VENR0i/NrFv0UNJApM67DksMMcjLlNiUzWWhSjX06P050LCoq7iCtw1TbrpmMW29XZT3W7r6TMb7NzXgbskszbvrj0Uzap2ajpl5g8Fj95lK0AvkaN8PHMXxoWOjZdbJp7t2aba6XrvMxhg0zIOfC4mgVyfzZAKeVfu7qhpYh7c7XxppllynenRx2q6ltd76YtJZuYKsn9SS20BkNaWqtMmG3y5TqKC2TziJNOhbi1AVXPea9xdT0UfN2am9gpMGkZ1I+8KZzmeJ/w6yer8b+dX08o9qv8vtbVL0tg/Xp8YIfakiriSz+HnoCtAvWjJvlwPX8M8PzwurAtD0i9XPYLdPP3uPDSnrUOzo+6J0cHP3ZP3wVvjoMj/7o9E4O/3HacDGSTu/lPNJbkiyyMqCmyPFw1npdJz2pTjgYTLU2dHLU6XV6aCJ0fs5ckayMWX0KwFxPslq0G5X2id8MVIa38Nl2Vca4G+C6cJlXoXdPw00TdaY46n6IaerjjwY0XM76BwFNMYLDezqfD5mBO52VJT7+VAAa5X6AeaQ5JoAL0oS7ZEhoOGKZgS0Qf7upkvV38hiEOkDFzKdrgb9oQB9g1vokAQvsNxS8bslyUAY0BZa4zyjmFd2ZF3nQ9wWo5rO2iaL6fgVmlLJbaQeN6nL9/rZPAzqsvl3I3dmKajbFUsimXmepFjuKezanGRPjguEIlXqemAz1lVL9PYJP2qD+p7Grta0yn3sK17yW5cJIvh8uB2VZ/gu2iDw8 sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Modify user permissions and other settings. --- --- id: update-security-policy-organization-name-api-v-1-security-settings-post title: "Modify security policy" description: "Modify organization-level security settings. Possible setttings include whether external users can be invited into this organization, whether certain login methods are permitted by default, and whether users managed by this organization are permitted to participate in outside organizations." sidebar_label: "Modify security policy" hide_title: true hide_table_of_contents: true api: eJztWl9v27YW/yoEn+4AxUmLArvQW5t2QLY1CZK0L4Eh0NKxxZUiWZKy6xn67sMhKVuyHdtp7rY010+JJfLw/M5/Hp0FdWxiaXpPbyGvDXdzcgvOcTmxdJjQAmxuuHZcSZrSj6rg4zlRZsIk/5Ph0xMBUxDEtptt3Dwg18paPhLgH/lnhMtc1AWQWQmuBEPgmwMjmSC1BWNJziQZAeFyyh0UhEuniCu57R2YLHfnYBzjkgg14ZJU4EpVWMIMEA2m4g5pjOakgDGrhUsIk8VybziwYpJNwqqNc9YIOUU0M47nXDOHPBJVO8sL6G2yA5pQpcH4XxcFTWmtC+agFe61EjyfZ1l3UyZZBVnGNM+mr7JWklkryUwr62hC2xc0vV/QX2fubZ6Dte+AGTA0vR82w4RqZlgFDoz1q5AwTenGYTShHPWpmStpQg18rbmBgqbO1JBQm5dQMZouqJtrJGCd4XJCE+q4E/jgqiuoS6TY4PFICKx7p4o57l6nmyvpQDp8xbQWPPf7T/+waFyLzrFKwtXYI9AGpek4WHyug/S+gCefK2kdTSkTQs0yLkeqlkXmrScoo8NwkDv5Dea0SeiUiRo6+EZKCWCys/6zX9E0SbtEjf6A3PWEdd/lpyU6XNEI3vIWubsIzF2seLsJoqJN8hiQqnbPGOVV5O4JMKOzZh4uFFn06v0YuYPK7rKdgHB10ohZnmes9h7QEr/DRfvk4d91JPAOKb2tXfk7BqKPnuMtgNcZULzIN45O+s5a17zY5odjZSqGRPyCB/zyE75r0NUdTMz3EbxY7Y30DhHONhRb+OjI8Ori/XlPfJh7OOaeikvmlPEmE+Q5vwxhLR5VMa0RRLro6jT91/UfFLyXj6MZ7DKDpnMQM4bN/5bo9T5Enc7Jq8B1gCH2juiY48OJacMqXmRm25W0HiWBHzjtPZjRDhTAMSEeI+ExIR7N4PkkRE8/rr6Br5ElA1YraYNKX5+9wT/95sFt7S+s41qQm7gYtfDm7Cxq/7C7Yd94rGOu7phRECaYjlRuw5KlVBaUyXmMiH11Y4iKT2QthPe5dTOMvx++Gt/5vz7wO8bFrqXvwwpvitYxmX83dxft/n3Kj/JKWnsMBJbM9p0YPhijzFJZ690gXFEQJcnNL+c///fsZ3JCLADBx+2eQTCX9X0F6STIN2ev/mkDaENNbWTK5ZQZzqRLAdHaFCNglpdMCJAT2BKJnrsJJHTF/SPyP+KWW+BuKVxeTG0RGmQPqye2tg4K7Z5Wh9PreiR4fkzc/4SMd2XFt8F+Scxjhx61bvadU1FC8rwTIfrx7a4E318mVW0d0UZNsU3MiDa8YmZOUFMgXYxwJDdQ4E8mBgcYsoRZ5hveT9X1Jcy8lg/FkatKC3DYzhfjEwtmynOIvXcDE25dKGEOATFlgmNXPIMKo98TkXyO1D4gsceoBQgmHaMEUWPiSiCeHcKKwoC1+FXg+uKSjGCsDJAJ45LLCWG+iiH+0wTgL1VLdwhoAxZcpp+uuWtm7UyZ4gYJXl9c/m2QtVE5QIGonSKef79HRwYOtdd2/VOB34JrsT/e+yTMloz/z3RqwdU6y1WxWSc8Hlutz1UBhyJDTrnkGDdWuMbKdCG0OB374mFK/32u1oTl8WvVARAdM+7J6JDIbmS54CAdsaWqRdExthBhLFjrP8rJghTcasHmHfO1IMAjIjY3ABiDOof3zn10Jg5l0d7kd6yejtXTsXr6t6unTnm0V+A/RCXVz58HYfpxs22nRNqL9GVWU92CYq8IXkDxEauL/VB/zCIkWb/p7AX6Em9GPr14CWZOfQH5vR0uH2TJnSfxxD5nt0W2rVJcNag325efJKYgZfifUIT+5ZtjA/v/qoF9qRz5Bb/4evW/fv2s2tcxgiCnO5TfkrgrwQCZMesrLDUSUJEZdyWZq9qQOM83eD7WsYyo7RDB8jLVl6tQee/t+lkPlbu/qxzfVnayC9lHO+nq40FPOiRmI6fhwOSh+M2V7BnyNSbDnZ8BlxJ6cpzsins/Z9vjpa98rGU4DPxBOpxhxWXhbuDnZ/yAq59GTenpYmNetTllmp9OX522M7An7XCsn4s103bgtTaCprR0Ttv09JRpPdBGFYOlkwwc5KU3rZbSLTpmsJlfZ+4GxgZsea7UF95VLdP8N/+91I/N5uF1ezmjJuwK2S2Lb5tkc0h3SQ85pHHQFn+PwgKUCkaMm9Uc7YdvDG8LuDeOduAsrfepsfIUlz4SMZKltyTU1hVemnqvW2ck8eaBSgZjg7KmrwdngzNkHpVSMR+8Isw4/b0c9Q4fktejaicUHufFD5oXjzbh4Js71YJxieL3lryIPnFP020z3ExzVN6rznD4yjGGCS3Rr9J7uliMmIVPRjQNPv5aA5rE/RC923B0S+88BfcuWtB0zISFHXr9z00MIT+Rh/hvHUeupgxSShPqx5u2TKQ3wyahJbDCD7Mv4rrzcOTJXYhOLZ2NDIvJI+xAh9Nu59phJ/RcX93e0YSO4sR65S9e1LAZxkk2CzwrvUw3/tmCCiYnNcPvqzTQRM9t+00RevTppP2nk/L6Ulkswgpf2TbNUkihWG6GTdP8BSW8ZWM= sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Modify organization-level security settings. Possible setttings include whether external users can be invited into this organization, whether certain login methods are permitted by default, and whether users managed by this organization are permitted to participate in outside organizations. --- --- id: upload-snapshot-organization-name-api-v-1-uploadsnapshot-post title: "Upload a snapshot" description: "Create a snapshot by direct upload. This triggers snapshot evaluation and rule processing." sidebar_label: "Upload a snapshot" hide_title: true hide_table_of_contents: true api: eJztWktv2zgQ/isET7uAaifdAl3o1mZToN02DRK3lyAQaGlssaFIlqTsqob++2JISZZiO3aa7RM92ZKGM/PNiyOOVtSxuaXxFb2UTNtcOUuvI5qBTQ3XjitJY3pigDkgjNiGhkwrknEDqSOlFoplIzLJuSXO8PkcjF0TwoKJkiEfwmRGTCmAaKNSsJbL+YhGVGkwnuBlRmMa2LW6JIkycyb5Z0+QSFZAkjDNk8VxEihtR6mVdTSiFtLScFfR+GpFXy3dsxRlPQdmwND46rq+jqhmhhXgwFhPhWxpTDdE0YhyhK+Zy2lEDXwsuYGMxs6UEFGb5lAwGq+oqzQysM5wOacRddwJvPG2x5GcIce6jjp5EtxSmZtWyscSTDUQM2PCDuQwWb2deZWHEpFpc0eWQlDE2Opw1kjpSzZKwFcWe4EiaryDjMG65yqrkNltK6ZKOpAOHxWlcFwz48YzZYpHGXNe/FoRbTBYHAeLVzOOknarF1FkwxyN6ZRLZiqvMHdQ2G1O2yRuSZgxrBqge8E9uo5CTT9A6gZWvAr69RahBZIHxnddo1QDVitpgxkeHx3hzzBjL0sf9rNSkIuGmA5szbQWPPVixx8srtltaPgEaVKWPLsr1k8/QUreIdE+u6zZ9YzzbmCXTueA98nRMYr+QvWtY67su5xLB3MwPeUvA0mnuJdlMRhKI2MuF8xwJl0MxihjY1a6PElzJgTIOfT4THB13V3vttbE/9ZYaB3j4i7SfwJFjflqHZPpnUF/V06+bNfXEV1rH6+oktAwG1rutjEQt9wClwmhlpAlBbhcZX5pl2aH8p4yy9MEJWwI2BNP/lk/z5DTs9Llr9WcyzdeJ2+XuxVQPEu3YAslc7d72rK+X8WGV0/T83IqeOp9lHFM34JL5pTpxXB1Fkp2w6FgWqP8eNU32EbIf3PjBuvt1eM72riubxf0Nc2zEL/kTRO/B4q6HfY9qWghedKrEMPyPMmBlBYMKUrrsB9a8Az7K214wUxF0FMgXVPhSGogw0smRgcEsoRlItA7D/X1GSy9lw/FkapCC3BALIjZIwtmwVMgXhViYM6tC43eISAWTPCMOUigwOr3QCTvG26nyOw+bgGCm45RgqgZcTkQrw5hWWbAWmyDz1+ekSnMlAEyZ1xyOSfM773EKb+CpakqpTsEtAELLtEP99w5s3apTHaBDM9fnn01yL6VhwxRO0W8/n6NbhQ4NF5b+ocCvwTXYr9/9klYdor/bz614EqdpCrb7BPuj63UJyqDQ5GhplxyrBtrXDNl+hBanI7deJiyIl5jwlLkaQ+C6JhxD0aHTO5GlgoO0hGbq1JkvWALFcbiK2XzmplxqwWreuFrQYBHRGxqALAG9YQP5N57Jw5t0d7N73f39Lt7+t09fe/uqdce7TX4T9FJDffPgzD9vLttr0Xai/TX7Kb6DcVeE/wCzUfTXeyH+nM2IdHtN529QH/FNyO/vXgLJk7dgPzSEy5fZMnEs9hnieZYMGr3o8CjO5HrH5Ft6xT7R5S3rfVO4hakDP8Mfnt/cvTkW59ffon1fpbTy4c5dtiOwSke6fbOyIeeRIqMKEkuXpw8/fvoKXlELADB2+2a0bYIOFOOvFClDO4//mvzhP4ijEXIqXTcVWSiFHnNzNyb9cnjxz/UeXdTclDxO6KlZTHJwQBZMutbMjUVUJAldzmpVGlIMw4a/Tjh1JVg3HIGb19DuwqVDp7elrWrP36tUnxa2PldyN7Yed8fO1PvkCKPmgaB0a6Cz5UcRP457p67MbzvWejBhbVv7v2abS+wzQyZTQU0KeT1Ci8TOLMN02A/uo3peLUxZ6vHTPPx4ng8nLON/QjZLNrZcGkEjWnunLbxeMy0HmmjslGXIiMHae4Dqx08X2Jahoh5tXQXMDNg8xOlbnjfsUzzf6Fqh7BpeBx1A9qwKmyGSfO0jjbn2R0/1JA2Q1u8ngaC2mfKTHnKLvIb3UmXAxG1ZYHvToPHbYqR5gUEXQfGBhcsHo+ORkeoFJq6YL4kNeqHYV7ve4HbdbVX277uxwWNdRx8cmMtGJeosPfpqomNKxpvG/wzzRHuMY3oMEBoRDFoc4yv+IquVlNm4Z0RdY23wzQdAyfjPjjX8/QbqAZDf9QddfNVagd1M6hfk17jheFIu13KTjP/cdGk6J9kl13a0JRVX2ary6aV6us6ojmwzH9ZsWroToLIR5OQ/S2fbcN9RB4WYVRr1yPf2PAQepfd528vJzSi0+abgsK/DPkJvucbrf/iFx8Rbc95GoRNckTtn97OMQS/WgUK31HWdWeL0KTW13Vd/wf9m0T6 sidebar_class_name: "post api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Create a snapshot by direct upload. This triggers snapshot evaluation and rule processing. --- --- id: upload-snapshot-status-organization-name-api-v-1-uploadsnapshot-status-get title: "Check snapshot evaluation status" description: "Check on the status of an in-progress snapshot evaluation task." sidebar_label: "Check snapshot evaluation status" hide_title: true hide_table_of_contents: true api: eJztWt9v2zgM/lcEPd0BXtIOA3bwW9frDt1tvaI/9lIUhmIzsVZF0iQ5uSzw/36gZLtykyZpu9vWYU9dbIr8PpKiaHFL6tjE0vSKnkumbamcpdcJLcDmhmvHlaQpPSwhvyFKElcCsY65yhI1JkwSLl9ooyYGrCW2UUBgxkTFcC1xzN4MaEKVBuOfHBc0pZUWihWtwXOvMMuUmTDJv3ixTLIpZBnTPJvtZ0G+1Z8FBNkEHE2ohbwy3C1oerWk7+buIM/B2jfADBiaXl3X1wnVzLApODDWS6FumtIVezShHOlq5kqaUAOfK26goKkzFSTU5iVMGU2X1C00KrDOcDmhCXXcCXzwT6SRnKDGuk46e1XFi9bE5wrM4lE2LlFLjawMWK2kBYviL/f28E8/bueVd8a4EuSsEaYJzZV0IB2KM60Fzz3e4SeLa5YRBG0wbI4HC9xmppIS0dzCGyklgMkI37ElZ41YnVAHZsolc8hww6KLW7EaiTmzyNjYgcks5EoWHgCTi3/GPoCNHi4dTMBQ9HHzSFZCUHROq/kMdZED1EXOG12Y3mNWCUfT/RpBhrVq9Aly1wvKVcy6xyYycbkmmzt31zVaeLW3jwwe6fmQ75EDW+K3GIJV2pHxtqzDrDMy5XLGDGfSpWCMMjZllSuzvGRCgJxAHAhcXXe/70/DC/+3Rlc6xsUm0T+DRI2pbx2TOayNZrNuUzCP2/V1Qm/Rp0uqJDTK+p676wzkLdfQZUKoORTZFFypQrZxB1P7EN0jZnmeoYUVA1tyzL+LaL5BTQeVK9+rCZcfPCbvl80AFC/yNdxC9bk/PG2d2g6x0RUhPa1Gguc+RgXHyuO3hzJRDi9OQvVrNEyZ1k0JiRy2kvLf3LnBe1txfEcf19F6ZgxbRPoPQv6SD03+7mjqbtpHVtFD8jCqEP2T5aIEUlkwZFpZR7RRM14AYUQbPmVmQTBSIF1T4UhuoMCfTAx2SGQJ80xgdJ4a6xOY+yjvyiNXUy3AAbEgxi8smBnPgXgoxMCEWxeamF1IzJjgBXOQwRSr3xOZfGy0HaGyh4QFCB46Rgls2LB983AIKwrfs40W5PT4hIxgrAyQCeN40hHm2wbilF/B8lxV0u1C2oAFl+mnR+6UWTtXpjhDhafHJ/8bZW1UDlAga6eIx+/X6AbArvnayj+V+Dm4lvvDd5+EeQf8q8XUgqt0lqtitU94OLdKH6oCdmWGSLnkWDdueY2ViSm0PB278TTlgnjEhOWo0+5E0THjnswOlWxmlgsO0hFbqkoUUbKFCmPBWiyWTBak4FYLtojS14IAz4jY3ABgDYqM9+w++CQObdHWw+9X9/Sre/rVPX3v7ilqj7Y6/Fl0Uv3zcydOz/e0jVqkrUx/zm4qbii2uuAnaD6a7mI71efZhCR3v3S2Ev0Zv4z88eI9mDl1A/KxN1y+yJILr2KbJ5prwaQ9j4KO7kYuviJb1ynGV5R3vXUp8QhShn8JN7Kv9l596/vLx3jvudxePi2w/XYMjvBKN7re70cSJQoc3Zy9PXz9x95r8oJYAIKP2zWDdRlwohx5qyoZwv/y5Q91fd1UEES6IfitiosSDJA5s77DUiMBUzLnriQLVRmCjgfrBj9OdnQVFU+Q3sdU369C5b23d23d1+6+Vzm+ndrJJmYf7CSOx707aZeajUiDweS++s2V7CXyKR6G93P4GHnoyXUydvd2ZOvrpe98rGUjAeRIOhxIolj4NqApDcNKP1lM6XC5Mnush0zz4Wx/2J91Djvw2EO3A8zKCJrS0jlt0+GQaT3QRhWDbp8MHOSlz652OnqOezOkzbu5O4OxAVseKnXD4+gyzf+GRTujzMPr9vuMmrAqHHBZ87ZOVoeunT5ESJuhJv4eBYHab5ex8pJd+jfYSbcREmqrKX4P9V63+4w0HxUYPzA2xGH2crA32ENQWlk3Zb4uNfDDEHvdkLrzcS+oUb37CgPwxiMO/nVDLRiXCNLHcdlkxRVN102kmeZIcZ8mtJ8aNGkz+zqhpcJSd0WXyxGzcGlEXePjMGbGlCm4z82CpmMmLGzg+ttZs3d+J/fhvoHF7TwbuaKIzzcfpRFG9GvbbFNULmKbLZZVz9XXdUJLYIX/bwDLRg4TVbtIw8pBhiy6XfvX0QWGoLlkacfXIYuT9h9Rne+jWy6DhG/n6roDGzrE+rqu6/8AFZGprA== sidebar_class_name: "get api-method" info_path: Reference/API/invariant-instance custom_edit_url: null hide_send_button: true --- import MethodEndpoint from "@theme/ApiExplorer/MethodEndpoint"; import ParamsDetails from "@theme/ParamsDetails"; import RequestSchema from "@theme/RequestSchema"; import StatusCodes from "@theme/StatusCodes"; import OperationTabs from "@theme/OperationTabs"; import TabItem from "@theme/TabItem"; import Heading from "@theme/Heading"; Check on the status of an in-progress snapshot evaluation task.