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. For more information see the Roles section in the Secure Workload User Guide.

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.

You can delete a scope only if you have the root scope owner privileges. Site Administrators are the owners of all scopes.

Deleting a scope impacts the application inventory membership of the parent scope (the workloads that are members of the parent scope). After you delete a scope, the status of the parent scope changes to draft changes. Commit the changes along with the dependencies such as workspaces, policies, and config intent. For more information, see Commit Changes.

You cannot delete scopes with dependent objects. An error message is displayed under the following circumstances:

• A workspace is defined for the scope.

• An inventory filter is assigned to the scope.

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

• An agent config intent is defined in the scope.

• An interface config intent is defined in the scope.

• A forensics config intent is defined on the scope.

  For more information on scope dependencies in the Review Scope/Filter Change Impact page, click the Dependencies tab. Delete redundant objects before you delete the scope.

  Note	Delete scopes that are without any child scopes. To remove a root scope, remove the VRF first from the Tenants page.

  1. From the navigation pane, click Organize > Scopes and Inventory.

  2. Click the Scope that you want to view the corresponding child scopes.

  3. Choose the child scope that you want to delete.

  4. Click the Delete button next to the Edit and Add buttons.

  5. Click the Review Scope Change Impact link to review the scope changes before deleting the scope.

  6. Click Back to close the page.

     

     

  7. Click Delete to delete the scope.

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.

To invoke scope suggestion for a desired scope user should locate on the scopes page and select it.

In the window, user can browse the inventory, uncategorized inventory items, i.e. those items that belong to the current selected scope and that do not belong to any of the current selected scope’s child scopes. Clicking on the uncategorized inventory items allows one to view this list.

After selecting the scope user can click on Suggest Child Scopes, and click on Start Scope Suggestion (or click on Rerun, in case this is not the first time). Note that the input for a scope suggestion run will be the uncategorized inventory items.

User can set the date range as input for scope suggestion and click on Suggest Scopes. A scope suggestion run is often fast under medium overall load, and takes only a few minutes for processing ten to thousands of endpoints, with tens of thousands of conversations.

The output is shown to the user as a list of candidates, currently up to 20 groups (shown), each accompanied with information such as group confidence (quality), a candidate scope name, and queries. Each discovered group has an associated Group Community Confidence, the possible values being: Very High, High, Medium and Low. This is a measure of the Community property of the group: the higher the confidence, the higher the community property of the given group of endpoints (many edges inside the group, relatively few edges to outside). Currently, the subset of groups picked to be shown are selected based on the Group Community Confidence. The groups discovered can currently fall under one of these four group types:

• Generic Group: Any group discovered via machine learning based on the community property. Note that any group that is not explicitly designated with the special types below is a generic group.

• Common Service: This group consists of endpoints that communicate with much of the input inventory. These endpoints could be running some kind of shared service(s).

• Common Service Clients: This group consists of endpoints that only communicate with the Common Service group.

• Ungrouped: This group consists of endpoints that cannot be grouped since they don’t have sufficient commu- nications.

The user can click on a discovered group to view the list of queries generated for the selected group. The user can preview the inventory covered by the query which will closely define the discovered group. The queries consist of IP-ranges, subnets, host names and user uploaded labels. There is a confidence measure associated with each group called Query confidence which can have one of the following range of values Perfect, Very High, High, Medium and Low. For query generation, first the groups are discovered via graph processing and machine learning, then the queries are generated for each group. Query Confidence is a measure of how well the query can cover the endpoints. A query confidence of Perfect indicates that the query exactly covers the suggested (discovered) group. On the other end of the spectrum, a Low query confidence indicates that the query significantly misses out on exactly capturing the suggested group, which means that the query covers many Extra IPs (not part of the discovered group) and/or has many Missing IPs (not covered by the query).

The user can click on + Scope button which will take the user to an edit window where the user can edit the group name and group query. The user can examine a query, the IPs that it matches, and decide whether some IPs need to be added or removed by adjusting the query. Once satisfied, the user can then click on Next, to review and convert the group to a scope on the draft view canvas.

After the user has converted a suggested group to a scope, the group slot turns green and the Uncategorized Inventory Items count decreases.

The user can repeat the process of scope creation from the remaining list of groups. The recommended workflow is to create one or more scopes and then re-run scope suggestion. A zero count for Uncategorized Inventory Items indicates that there is no inventory left to be further scoped (for the currently selected parent scope).

After the scope creation process is done (the uncategorized count is 0), user can repeat this process on the newly created child scopes in order to generate a deeper scope tree as desired.

Note	There is also a possibility that the uncategorized items in a scope do not partition well (e.g., do not form communities). In that case, the algorithm may return no groupings (an empty result).

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 VULNERABILITIES tab displays the CVEs identified by Secure Workload 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

The inventory filter created with CVE ID allows searching hosts affected by a specific CVE.

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

The following operations are supported:

• =: Returns hosts with packages affected by a CVE ID.

• ≠: 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 returns hosts affected by a CVE).

• doesn't contain: Returns hosts with packages not affected by a CVE present in the input string (entering cve returns hosts not affected by a CVE).

• matches: Returns hosts with packages affected by a CVE that matches the input string.

The Common Vulnerability Scoring System (CVSS) based filter allows searching for hosts that have CVE with the specified CVSS V2 or CVSS V3 impact score by entering the score in numeric format.

For example, to search for hosts with CVEs of CVSS V2 impact score greater than 7.5, the query is CVE Score v3 > 7.5.

The following operations are supported:

• =: Returns hosts which have CVE with the specified CVSS V2 or V3 impact scores.

• ≠: Returns hosts which do not have CVE with the specified CVSS V2 or V3 impact scores.

• >: Returns hosts which have CVE with CVSS V2 or V3 impact scores greater than the specified CVSS V2 or V3 impact scores respectively.

• ≥: Returns hosts which have CVE with CVSS V2 or V3 impact scores greater than or equal to the specified CVSS V2 or V3 impact scores respectively.

• <: Returns hosts which have CVE with CVSS V2 or V3 impact scores less than the specified CVSS V2 or V3 impact scores respectively.

• ≤: Returns hosts which have CVE with CVSS V2 or V3 impact scores less than or equal to the specified CVSS V2 or V3 impact scores respectively.

Inventory filters can be created using access vectors and access complexities to identify vulnerable hosts. The following operations are supported in the filter:

• =: Returns hosts with packages affected by vulnerabilities matching the filter.

• ≠: Returns hosts with packages not affected by vulnerabilities matching the filter.

Attack vectors, attack complexities, and privilege required to influence the CVSS V3 score can be used in inventory filters. The following operations are supported in the filter:

• =: Returns hosts with packages affected by vulnerabilities matching the filter.

• ≠: Returns hosts with packages not affected by vulnerabilities matching the filter.