env: prod

env: prod

prod,test

For labels specific to AKS, EKS, and GKE, see also Labels Related to Kubernetes Clusters.

The following information applies to plain-vanilla Kubernetes, OpenShift, and to Kubernetes running on supported cloud platforms (EKS, AKS, and GKE).

For each object type, Secure Workload imports inventory live from a Kubernetes cluster, including labels associated with the object. Label keys and values are imported as-is.

In addition to importing the labels defined for the Kubernetes objects, Secure Workload also generates labels that facilitate the use of these objects in inventory filters. These additional labels are especially useful in defining scopes and policies.

Service-specific labels

The following labels are generated for services only.

Key	Value
orchestrator_system/workload_type	service
orchestrator_system/service_name	<Name given to this service>

• (For cloud-managed Kubernetes only) Services of ServiceType: LoadBalancer are supported only for gathering metadata, not for collecting flow data or for policy enforcement.

Tip

Filtering items using orchestrator_system/service_name is not the same as using orchestrator_system/service_endpoint. For example, using the filter orchestrator_system/service_name = web selects all services with the name web while orchestrator_system/service_endpoint = web selects all pods that provide a service with the name web.

 - apiVersion: v1
 kind: Node
 metadata:
   annotations:
     node.alpha.kubernetes.io/ttl: "0"
     volumes.kubernetes.io/controller-managed-attach-detach: "true"
   labels:
     beta.kubernetes.io/arch: amd64
     beta.kubernetes.io/os: linux
     kubernetes.io/hostname: k8s-controller

Users can use the Scope filter to quickly identify different scope details such as overlapping scopes and query. The filter feature is also helpful in identifying query changes, parent changes, etc.

Examples:

Has Overlaps

Example of Scope Overlap

For more information see Scope Overlap

Parent Change

Scopes that are moved in the draft but not yet committed.

Scopes are defined hierarchically, the full query of the scope is defined as the logical ‘and’ of the scope along with all of its parents. Using the example above, assets assigned to the Workloads:FrontEnd:Mongo

Scope would match:

vrf_id = 676767 and (ip in 1.1.1.0/24) and (Hostname contains mongo).

Where vrf_id = 676767 comes from the root scope query and ip in 1.1.1.0/24 comes from the parent scope query.

Note	It is a best practice to not have overlapping queries at the same level. This removes the importance of ordering and reduces confusion. See Scope Overlap

You can grant Read, Write, Execute, Enforce, and Owner abilities on Scopes. An overview is provided below, for more information see Roles.

A User is given access to a “sub-tree”. That is, the given Scope and all its children. Using the preceding example, you have the Read access to the Workloads:FrontEnd scope would, by inheritance, have read access to all the scopes under Workloads:FrontEnd including:

• Workloads:FrontEnd:Mongo

• Workloads:FrontEnd:ElasticSearch

• Workloads:FrontEnd:Redis

• etc. . .

It’s possible to define Roles with access to multiple Scopes. For example, an “Mongo Admin” role might have Owner access to the Scopes:

• Workloads:FrontEnd:Mongo:MongoServer

• Workloads:FrontEnd:Mongo:MongoDBArbiter

Roles and Capabilities allow you to have horizontal access to the Scope hierarchy.

Scope Abilities are also inherited. For example, having the Write ability on a Scope allows one to also Read that information.

Every user can view the scope tree they have access to. Users who have the Owner ability on the root scope have the ability to create, edit and delete scope in that tree. To access this view:

In the navigation bar on the left, click Organize > Scopes and Inventory.

You can traverse through the complete scope hierarchy (up to the root) for any Scopes you have access to. This complete traversal provides context as users can create policies to any Scope. Several actions can be performed on this page:

• Click the chevron in the scope hierarchy to show that scope’s children.

• Clicking on a scope card will update the pane to the right to show details about that scope as well as a filterable list of all of its inventory.

There are some shortcuts provided on the scopes page to help the user in scenarios they need to search for flows where one or both endpoints of the flow fall within a provided scope.

After selecting desired scope in the scope tree (left side panel), as shown in the figure above, user can choose between the following three options:

1. Flow Search - As Consumer provides shortcut to the flow search page to help search for flows with selected scope as Consumer Scope for the flows. In other words, consumer or source endpoint in the flows belongs to the selected scope.

2. Flow Search - As Provider provides shortcut to the flow search page to help search for flows with selected scope as Provider Scope for the flows. In other words, provider or destination endpoint in the flows belongs to the selected scope.

3. Flow Search - Internal Traffic provides shortcut to the flow search page to help search for flows that are completely restricted to the selected scope. In other words, both endpoints of the flows (consumer and provider) belong to the selected scope.

While adding scopes, it is recommended to avoid overlapping scopes. When scopes overlap, policies generated for overlapping scopes can potentially end up confusing end users. This feature proactively notifies the user if there are any overlapping scope membership, that is, the same inventory belongs to more than one scope at the same depth in scope tree (sibling scopes). The goal is to avoid having the same workload exist in different parts of the scope tree.

To view which inventory items belong to multiple scopes, use the scope filter and enter the Has Overlaps = true facet.

The list of overlapping scopes and the corresponding overlapping IP addresses can be viewed by traversing down the scope tree and selecting the Overlapping Scopes tab.

Scopes can only be edited by users with the SCOPE_OWNER ability on the root scope. Site admins are owners of all scopes.

Editing a scope name

Editing a scope name happens immediately and can take several minutes depending on the number of child scopes that need to be updated.

Note	Flow searches by scope name will be impacted when changing the scope name.

Scopes can only be deleted by users with the SCOPE_OWNER ability on the root scope. Site admins are owners of all scopes.

Deleting a scope will impact the application inventory membership of the parent scope (the workloads that are members of the parent scope). . As a result, the parent scope will be marked as having ‘draft changes’. The changes will need to be committed and dependent structures will need to be updated. See Commit Changes.

Scopes with dependent objects can not be deleted. An error will be returned if:

• A workspace is defined for the Scope.

• There is an Inventory Filter assigned to the Scope.

• A policy exists that uses the Scope to define its consumers or providers.

• An Agent Config Intent is defined on the Scope

• An Interface Config Intent is defined on the Scope.

• A Forensics Config Intent is defined on the Scope.

  To further drill down on scope dependencies, you can visit the Dependencies tab from the Review Scope/Filter Change Impact window.

  These objects need to be removed before the Scope can be deleted.

  1. In the navigation bar on the left, click Organize > Scopes and Inventory.

  2. Select a “scope” then click again to display child Scopes. Select the child scope you wish to delete.

  3. Click the Delete button next to the edit and add buttons.

     

     Note	Only Scopes without children can be deleted

     Note	Root scopes must be deleted by removing the VRF from the Tenants page.

A scope’s application inventory query definition is defined by its query and those of its direct children. When this happens the scope is marked as having ‘draft changes’ and the scope’s query, workspaces, and clusters will not be changed until the Commit Changes background task is run. When a scope is in draft, the caution triangle is shown by the affected scopes icons, and the ‘Commit Changes’ button is shown on the Scopes page (top right) and should be clicked to run the Commit Changes background task.

Events that can mark a scope as in draft:

• Query update

• The query of any parent is updated.

• Direct child is added.

• Direct child is deleted.

• Direct child’s query is updated.

Changing the name of a scope does not change the draft state of the scope.

Note	The Commit Changes task is asynchronous. It usually takes several seconds but large scope trees can take several minutes.

Note	The scope update task will be completed when the root scope is no longer in draft. Refresh the page to get the latest state.

Site Admins and users with the SCOPE_OWNER ability on the root scope can view the change logs for each scope by clicking change log in the overflow menu in the upper right.

These users can also view a list of deleted scopes by clicking on the View Deleted Scopes link is in the overflow menu in the upper right corner.

Suggest Child Scopes is a tool that uses machine learning algorithms (such as community detection in networks) to discover groupings that could serve as scopes. This tool is helpful when building a scope hierarchy, and facilitates the process of defining more granular child scopes for a given scope. Candidate child scopes are shown as suggestions that can then be selected and added.

Description of Algorithms: A graph based on the communications among the unclaimed members of the parent scope is first created (note: unclaimed members are those that do not belong to any child scope of the parent), and the graph is preprocessed, for example the algorithms attempt to identify endpoints that communicate with sufficiently high proportion of other endpoints in the graph. Such a group of endpoints, if found, is displayed to the user as a candidate common services grouping. The rest of the graph is processed to detect groups that behave as communities, meaning roughly that the endpoints disproportionately communicate with one another more often (or on more provider ports) than to endpoints outside the group. Each such grouping may correspond to an application or a department within the organization. Such a partitioning can also lead to sparser policies among scopes.

Example:

Let 1 through 10 be individual endpoint IPs. Assume the input (communications) graph is as follows:

Then the endpoints 1 - 4, 5 - 7 and 8 - 10 will be grouped together because they have relatively high degree of communication (number of edges) among one another, and relatively low communications to other endpoints.

The inventory table under Membership view displays all columns by default. You can choose the columns to display. Furthermore, you can download the csv or json of chosen Membership columns and rows with an additional Diff column identifying whether the inventory is Gained, Lost or Unchanged. Be sure that all table selection desired for download is visible to the table view.

You can traverse down to nested dependencies by further selecting Review Dependencies

You can traverse back up the dependencies tree by selecting the selected Parent link:

The following are Scope Dependencies which may exist:

The following are Filter Dependencies which may exist:

The packages tab lists packages installed on a host and vulnerabilities affecting them.

Long-lived processes are displayed under the process list tab.

Vulnerability information is displayed for all processes in the process tree under the process snapshot tab.

The vulnerability tab shows a list of vulnerabilities observed on the workload.

For each CVE, besides basic impact metrics, exploit information based on our threat intelligence is displayed:

• Exploit Count: number of times CVE was seen exploited in the wild in the last year

• Last Exploited: last time CVE was seen exploited in the wild by our threat intelligence

This filter allows searching for hosts affected by a specific CVE or any CVE.

To search for a host affected by a specific CVE, provide the CVE ID in the format: CVE-XXXX-XXXX

The following operations are supported:

• Equality - returns hosts with packages affected by a CVE ID.

• Inequality - returns hosts with packages not affected by a CVE ID.

• Contains - returns hosts with packages affected by a CVE present in the input string (entering “cve” will return hosts affected by a CVE).

• Doesn’t contain - returns hosts with packages not affected by a CVE present in the input string (entering “cve” will return hosts not affected by a CVE).

This filter allows searching for hosts that have CVE with the specified CVSSv2 or CVSSv3 impact score. To search for hosts which have any CVE with impact score (v2 or v3), user can provide the score in numeric format.

To search for hosts which have CVE with CVSSv2 impact score greater than 7.5.

The following operations are supported:

• Equality - returns hosts which have CVE with the specified CVSSv2 or CVSSv3 impact scores.

• Inequality - returns hosts which don’t have CVE with the specified CVSSv2 or CVSSv3 impact scores.

• Greater Than - returns hosts which have CVE with CVSSv2 or CVSSv3 impact scores greater than the specified CVSSv2 or CVSSv3 impact scores respectively.

• Greater Than or Equal To - returns hosts which have CVE with CVSSv2 or CVSSv3 impact scores greater than or equal to the specified CVSSv2 or CVSSv3 impact scores respectively.

• Less Than - returns hosts which have CVE with CVSSv2 or CVSSv3 impact scores less than the specified CVSSv2 or CVSSv3 impact scores respectively.

• Less Than or Equal To - returns hosts which have CVE with CVSSv2 or CVSSv3 impact scores less than or equal to the specified CVSSv2 or CVSSv3 impact scores respectively.

Inventory filters can be created using access vectors and access complexities to identify vulnerable hosts. These filters support the following types of operations:

• Equality - returns hosts with packages affected by vulnerabilities matching the filter.

• Inequality - returns hosts with packages not affected by vulnerabilities matching the filter.

Attack vectors, attack complexities, and privilege required to influence the CVSSv3 score and can be used in inventory filters. These filters support the following operations:

• Equality - returns hosts with packages affected by vulnerabilities matching the filter.

• Inequality - returns hosts with packages not affected by vulnerabilities matching the filter.

Neighborhood geo exposes two directions of geo data:

1. Inbound : Aggregate view of flows from a Geo location (such as Country) to a Scope (or Filter/Cluster).

2. Outbound : Aggregate view of flows from a Scope (or Filter/Cluster) to a Geo location (such as Country).

Note that Geo view is based on the Source/Consumer Scope (Outbound) or Destination/Provider Scope (Inbound), and not on the direction of data. Within a selected geo view ‘Bytes Sent’ or ‘Bytes Received’ can chosen.

Exploration of aggregated node (Scope, Filter, Cluster) data has 3 versions:

1. Inbound: Aggregated flows with the selected node as a destination

2. Outbound: Aggregated flows with the selected node as the source

3. Paths: Aggregate view of flows where one source node and one destination node are constrained. Note that these are aggregated node-to-node edges, but are otherwise unrelated.

Inbound and Outbound Exploration

Choose to enter a node of interest. And select either Inbound or Outbound

A radial tree will be shown with the selected node in the center, and adjacent nodes up to two hops away radiating inward. Below the radial tree will be a list of paths toward the selected node.

Path Exploration

Selecting “Paths” instead of inbound/outbound will allow specifying both a source and a destination.

Filter Options

The neighborhood graph can be filtered by specifying additional filter options. Currently supported filters are Provider Port and Protocol.

Clicking any path listed below the graph, will expand with details about the path and provide links to flow search.

Path Details

Path details contains tabs showcasing different groups of metrics: Total Traffic, Bandwith, Drops, TCP Control Plane, Bottlenecks, Latency.

Note	some metrics may not be available depending on flow data collection method.

Total Traffic

Bandwidth

Drops

TCP Control Plane

Bottlenecks

Latency

• To configure alerts click the ‘Manage Alerts’ button. This opens the Alert Configuration Modal. Different types of alerts are available for Nodes, Edges, and Paths.

• To see what alert trigger configurations are available for each, the user user could selected the type (such as Node), then click to see the options.

• After forming the alert trigger, the user could expand the alert configuration to change the alert frequency. The default frequency is ‘hourly’, but can be changed to ‘daily’.

Supported Alerts

Warning

Configured alerts on a subscope or filter will not be automatically deleted if the subscope or filter is deleted. New clusters with equivalent queries will remain relevant, but if a cluster or filter is no longer used in the latest live analysis policies, then no alerts will be generated that use those clusters and filters, and the outdated alert configurations will remain. Users should periodically review their configured alerts to make sure they remain relevant.

• A valid Data Tap must be selected for the Neighborhood alerts. Alerts will only be visible in the UI if they were successfully.

  • Alert publishers and notifiers can be chosen from Alerts → Configuration (Root Scope Owners or Site Admins).

• After configuring alerts and setting up data tap, alerts can be viewed in the UI under Alerts → Current Alerts.

  • User can use Type = NEIGHBORHOOD in the filter selection box. See Current Alerts for more filtering options.

  • Alert details can be seen by clicking an alert.

See Common Alert Structure for general alert structure and information about fields. The alert_details field is structured and contains the following subfields for neighborhood alerts

Note	Subject (interval name of node) is the neighborhood node that triggered the alert.

The internal_trigger fields are structured and contain the following subfields for alert trigger