Abstract: Techniques for microsegmenting network communication transactions from end-to-end over an entire network communication path between a client device and a workload. The techniques may include determining that a first layer of a packet traversing the communication path includes a first metadata tag associated with a first segmentation ecosystem applying a microsegmentation policy along a first portion of the communication path. Based at least in part on the first metadata tag, a second metadata tag may be determined that is associated with a second segmentation ecosystem applying the microsegmentation policy along a second portion of the communication path. The second metadata tag may then be embedded within a second layer of the packet such that the second segmentation ecosystem is capable of applying the microsegmentation policy to the packet along the second portion of the communication path.

Abstract: Provided herein are techniques to facilitate enhanced cloud access security broker (CASB) functionality via in-band application observability in which a CASB can be implemented in-line between the client device and an embedded application security service. In one instance, a method may include, obtaining, by a CASB from a client device, a first message for an application transaction involving an application operating via the client device. The first message can be augmented to include first security metadata and can be forwarded to trigger one or more actions by an embedded application security service associated with the application. The CASB may obtain a second message from the embedded application security service that includes second security metadata, and one or more actions can be triggered at the CASB based, at least in part, on the second security metadata included in the second message.

Abstract: Techniques for expressing, communicating, de-conflicting, and enforcing consistent access policies between an IBN architecture and a Cloud-Native architecture. Generally, network administrators and/or users of a Cloud-Native architecture and an IBN architecture express access policies independently for the two different domains or architectures. According to the techniques described herein, a Network Service Endpoint (NSE) of the Cloud-Native architecture may exchange access policies with a network device of the IBN architecture. After exchanging access policies, conflicts between the sets of access policies may be identified, such as differences between allowing or denying communications between microservices and/or applications. The conflicts may be de-conflicted using various types of heuristics or rules, such as always selecting an access policy of the IBN architecture when conflicts arise.

Abstract: Data related to operational performance of a plurality of nodes in a system is obtained and a first metric anomaly associated with a node of the plurality of nodes in the system is identified. The first metric anomaly indicates that data associated with a first metric is outside a threshold range. Second metrics related to the first metric are identified and it is determined that one of the second metrics is an anomaly. Third metrics related to the second metric are identified and it is determined whether any third metric is an anomaly. The second metric is identified as a probable cause of the first metric anomaly when it is determined that no third metric is an anomaly. A report including information associated with the probable cause of the first metric anomaly is transmitted to a user device.

Abstract: Techniques for expressing, communicating, de-conflicting, and enforcing consistent access policies between an IBN architecture and a Cloud-Native architecture. Generally, network administrators and/or users of a Cloud-Native architecture and an IBN architecture express access policies independently for the two different domains or architectures. According to the techniques described herein, a Network Service Endpoint (NSE) of the Cloud-Native architecture may exchange access policies with a network device of the IBN architecture. After exchanging access policies, conflicts between the sets of access policies may be identified, such as differences between allowing or denying communications between microservices and/or applications. The conflicts may be de-conflicted using various types of heuristics or rules, such as always selecting an access policy of the IBN architecture when conflicts arise.

Abstract: Techniques for expressing, communicating, de-conflicting, and enforcing consistent access policies between an IBN architecture and a Cloud-Native architecture. Generally, network administrators and/or users of a Cloud-Native architecture and an IBN architecture express access policies independently for the two different domains or architectures. According to the techniques described herein, a Network Service Endpoint (NSE) of the Cloud-Native architecture may exchange access policies with a network device of the IBN architecture. After exchanging access policies, conflicts between the sets of access policies may be identified, such as differences between allowing or denying communications between microservices and/or applications. The conflicts may be de-conflicted using various types of heuristics or rules, such as always selecting an access policy of the IBN architecture when conflicts arise.