Network
Sysdig Network Security tracks ingress and egress communication from every pod. The Network Security Policy tool allows you to generate
Kubernetes Network Policies based on the traffic allowed or denied as defined in the Ingress and Egress tabs. The UI also allows you to view which policies are being applied in real time.
Prerequisites
Sysdig agent: 10.7.0+
If necessary, install or upgrade your agents.
Note: If you are upgrading and not using Helm, you will need to update the clusterrole.yaml manually.
Supported CNI Plugins:
Coverage Limits
- Communications to/from k8s nodes are not recorded
- Workloads with no recorded communications are not present in workloads list
By default, all pods within a Kubernetes cluster can communicate with each other without any restrictions. Kubernetes Network Policies help you isolate the microservice applications from each other, to limit the blast radius and improve the overall security posture.
With the Network Security Policy tool, you can generate and fine-tune Kubernetes network policies within Sysdig Secure. Use it to generate a “least-privilege” policy to protect your workloads, or view existing network policies that have been applied to you workloads. Sysdig leverages native kubernetes features and doesn’t require any additionl networking requirements other than the CNIs already supported.
Benefits
Key features include:
- Out-of-the-box visibility into network traffic between applications
and services, with a visual topology map to help identify
communications.
- A baseline network policy that you can directly refine and modify to
match your desired declarative state.
- Automated KNP generation based on the network communication
baseline + user-defined adjustments.
- Least-privilege: KNPs follow an allow-only model, any communication
that is not explicitly allowed will be forbidden
- Enforcement delegated to the Kubernetes control plane, avoiding
additional instrumentation or directly tampering with the host’s
network configuration
- Map workloads to network policies applied to your cluster, helping operators and developers understand why a pods communicaiton may or may not be blocked
- The ability to view the network policies applied to a cluster for a particular workload or workloads, with drill-down details to the raw yaml
Ensure your environment meets the Prerequisites.
Log in to Sysdig Secure and select Network. You will be prompted to select a cluster and namespace, then taken to the Network Security Policies page.
Next Steps
You can now generate policies, review and tune them, and finesse configurations or troubleshoot.
1 - Netsec Policy Generation
Generating KNPs in the Sysdig Network Security Policy Tool involves four steps, as described in the following sections:
- Set the scope
- Review ingress/egress and edit the detected communications as desired
- Review the topology map
- Click
Generated Policy and download the resulting file.
Subsequently, you can check the topology map to:
- Review applied policies
- Click into details for remediation if needed.
Set the Scope
You first define the Kubernetes entity and timeframe for which you want
to aggregate communications.
Understanding the aggregation: Communications are aggregated using
Kubernetes metadata to avoid having additional entries that are not
relevant for the policy creation. For example, if pod A under deployment
A communicates several times with pod B under deployment B, only one
entry appears in the interface. Or: If pod A1 and pod A2, both under
deployment A, both communicate with pod B, deployment A will represent
all its pods.
In the Sysdig Secure UI, select Network from the left menu.
Choose Cluster and Namespace from the drop-down menus.
Select the type of Kubernetes entity for which you want to create a
policy:
Service
Deployment
Daemonset
Stateful Set
CronJob Choose CronJob to see communication aggregated to the
CronJob (scheduler) level, rather than the Job, which may
generate an excess number of entries.
Job Choose Job to see entries where a Job has no CronJob
parent.
Select the timespan, i.e. how far back in time to aggregate the
observed communications for the entity. The interface will display
the Ingress / Egress tables for that Kubernetes entity and
timeframe.
Manage Ingress and Egress
The ingress/egress tables detail the observed communications for the
selected entity (pod owner) and time period.
Granular and global assignments: You can then cherry-pick rows to
include/exclude from the policy granularly, or establish general rules
using the drop-down global rule options.
Understanding unresolved IPs: For some communications, it may not be
possible to resolve one of the endpoints to Kubernetes metadata and
classify as Service, Deployment, etc.. For example, if a
microservice is communicating with an external web server, that external
IP is not associated with any Kubernetes metadata in your cluster. The
UI will still display these entities as “unresolved IPs.” Unresolved IPs
are excluded by default from the Kubernetes network policy, but can be
added manually via the ingress/egress interface.
Choose Ingress or Egress to review and edit the detected
communications:
Select the scope as described above.
For in-cluster entities: Edit the permitted communications as
desired, by either:
Selecting/deselecting rows of allowed communication, or
Choosing General Ingress/Egress Rules:
Block All, Allow All Inside Namespace, or Allow All.
For unresolved IPs (if applicable): If the tool detects many
unresolved IPs, you can:
Search results by any text to locate particular listings
Filter results by
Internal: found within the cluster
External: found outside the cluster
Aliased: displays any given alias
Unknown: unable to tell if internal or external.
Fine-tune the handling of unknown IPs (admins only) .
You can assign an alias, set the IP to “allowed” status, or add a CIDR configuration so the IP so the IP is correctly categorized and labelled.
Repeat on the other table, then proceed to check the topology and/or
generate the policy.
Use Topology Visualization
Use the Topology view to visually validate if this is the policy you
want, or if something should be changed. The topology view is a
high-level Kubernetes metadata view: pod owners, listening ports,
services, and labels.
Communications that will not be allowed if you decide to apply this
policy are color-coded red.
Pop-up detail panes: Hover over elements in the topology to see all
the relevant details for both entities and communications.
Review Applied Policies
Once policies have been generated, you can view the network policies applied to a cluster for a particular workload or workloads.
You can:
Topology Legend
When glancing at the topology, the color codes indicate:
Lines:
Black = resolved connection
Red = connection not resolved; communication not included in the generated policy. (Go to Ingress/Egress panels and select the relevant rows to allow the communication.)
Entities:
Blue = the selected workload
Black = other services and deployements the selected workload communicates with
Review and Download Generated Policy
When you are satisfied with the rules and communication lines, simply
click the Generated Policy tab to get an instantaneously generated
file.
Review the resulting YAML file and download it to your browser.
Sample Use Cases
In all cases, you begin by leaving the application running for at least 12 hours, to allow the agent to collect information.
Case 1: Only Allow Specified Ingress/Egress Communications
As a developer, you want to create a Kubernetes network policy that only
allows your service/deployment to establish ingress and egress network
communications that you explicitly allow.
Select the cluster namespace and deployment for your
application.
You should see pre-computed ingress and egress tables. You know the
application does not communicate with any external IP for ingress or
egress, so should not see any unresolved IPs. The topology map shows
the same information.
Change a rule: You decide one service your application is
communicating with is obsolete. You uncheck that row in the egress
table.
Check the topology map. You will see the communication still
exists, but is now drawn in red, meaning that it is forbidden using
the current Kubernetes network policy (KNP).
Check the generated policy code. Verify that it follows your
plan:
Download the generated policy and upload it to your Kubernetes
environment.
Verify that your application can only communicate with the
services that were marked in black in the topology and checked in
the tables. Then generate and download the policy to apply it.
Case 2: Allow Access to Proxy Static IPs
As a developer, you know your application uses proxies with a static IP
and you want to configure a policy that allows your application to
access them.
See the proxy IPs in the egress section of the interface
Use the Allow Egress to IP mask to create a manual rule to
allow those IPs in particular
De-select all the other entries in the ingress and egress tables
Looking at the topology map, verify that only the communications
to these external IPs are marked in black, the other communications
with the other services/deployments are marked in red
Download the generated Kubernetes network policy and apply it.
Case 3: Allow Communication Only Inside the Namespace
You know that your application should only communicate inside the
namespace, both for ingress and for egress.
Allow ingress inside the namespace using the general rules
Allow egress inside the namespace using the general rules
Generate the policy and confirm: everything inside the namespace
is allowed, without nominating a particular service/deployment, then
apply it.
Case 4: Allow Access to a Specified Namespace, Egress Only
Your application deployment A only communicates with applications in
deployment B, which lives in a different namespace. You only need that
egress traffic; there is no ingress traffic required for that
communication.
Verify that the ingress table is empty, both for Kubernetes
entities and for raw IPs
Verify that the only communication listed on the Egress table is
communication with deployment B
Download the autogenerated policy, apply it, and verify:
Case 5: Allow Access When a Deployment Has Been Relabeled
As a developer, you want to create a policy that only allows your
service/deployment to establish ingress and egress network
communications that you explicitly allow, and you need to make a change.
After leaving the application running for a few hours, you realize
you didn’t tag all the namespaces involved in this policy
A message at the top of the view will state “you need to assign
labels to this namespace”.
Confirm the situation in the different views:
Attach a label to the namespace that was missing it. After some
minutes, a row shows the updated information.
Whitelist the connection appropriately.
Generate and download the policy and apply it.
2 - Configuration and Troubleshooting
Kubernetes Network Configuration
Sysdig provides a Configuration page for Administrators who
want to fine-tune the way the agent processes the network data.
It contains three areas, described below:
Workload Labels
The Sysdig agent automatically detects labels used for the Kubernetes objects in a
cluster. Sometimes, there are many more labels than are required for
network security purposes. In this cases, you can select the two or
three most meaningful labels and use include or exclude namespace or workload labels to avoid clutter
in both the UI and your network security policies. For example you can exclude labels inherited by helm, and only include the labels that are required for each ojbect, like app and name
Unresolved IP Configuration
If the Sysdig agent cannot resolve an IP to a higher-level structure
(Service, Deployment, Daemonset, etc.) it will be displayed as
“unresolved” in the ingress/egress tables. Additionaly you can add unresolved IPs from the ingress or egress tabs by clicking the @ and creating a new alias or assigning it to an existing alias
You can manually enter such IPs or CIDRs in the configuration panel,
label them with an alias, and optionally set them to “allowed” status.
Note that grouping IPs under a single alias helps declutter the
Topography view.
Pod communication without an alias
Pod communicaiton with IP aliases
Cluster CIDR Configuration
Unresolved IPs are listed and categorized as “internal” (inside the
cluster), “external” (outside the cluster) or “unknown,” (subnet
information incomplete). For unknowns, Sysdig will prompt with an error
message to help you resolve it.
The simplest resolution is to manually specify cluster and service CIDRs
for the clusters.
Troubleshooting
Tips to resolve common error messages:
Error message: Namespaces without labels
Problem: Namespaces must be labeled for the KNPs to define
ingress/egress rules. If non-labeled namespaces are detected in the
targeted communications, the “Namespaces without labels” error message
is displayed in the UI:
Resolution: Simply assign a label to the relevant namespace and wait
a few minutes for the system’s auto-detection to catch up.
Error Message: Cluster subnet is incomplete
Problem: To categorize unresolved IPs as inside or outside the
cluster, the agent must know which CIDR ranges belong to the cluster. By
default, the agent tries to discover the ranges by examining the command
line arguments of the kube-apiserver and kube-controller-manager
processes.
If it cannot auto-discover the cluster subnets, the “cluster subnet is
incomplete” error message is displayed in the UI:
Resolution:
Preferred: Use the Configuration panel to add the
CIDR entries.
In rare cases, you may need to configure the agent to look for the
CIDR ranges in other processes than the default
kube-apiserver, kube-controller-manager processes. In that case,
append the following to the agent configmap:
network_topology:
pod_prefix_for_cidr_retrieval:
[<PROCESS_NAME>, <PROCESS_NAME>]
