cilium requirements below Most modern Linux distributions already do adminsystemreqs System Requirements docs cilium io Before installing Cilium please ensure that your system meets the minimum

Answer:
.. only:: not (epub or latex or html)

    WARNING: You are looking at unreleased Cilium documentation.
    Please use the official rendered version released here:
    https://docs.cilium.io

.. _admin_system_reqs:

*******************
System Requirements
*******************

Before installing Cilium, please ensure that your system meets the minimum
requirements below. Most modern Linux distributions already do.

Summary
=======

When running Cilium using the container image ``cilium/cilium``, the host
system must meet these requirements:

- Hosts with either AMD64 or AArch64 architecture
- `Linux kernel`_ >= 5.4 or equivalent (e.g., 4.18 on RHEL 8.6)

When running Cilium as a native process on your host (i.e. **not** running the
``cilium/cilium`` container image) these additional requirements must be met:

- `clang+LLVM`_ >= 10.0

.. _`clang+LLVM`: https://llvm.org

When running Cilium without Kubernetes these additional requirements
must be met:

- :ref:`req_kvstore` etcd >= 3.1.0

======================== ============================== ===================
Requirement              Minimum Version                In cilium container
======================== ============================== ===================
`Linux kernel`_          >= 5.4 or >= 4.18 on RHEL 8.6  no
Key-Value store (etcd)   >= 3.1.0                       no
clang+LLVM               >= 10.0                        yes
======================== ============================== ===================

Architecture Support
====================

Cilium images are built for the following platforms:

- AMD64
- AArch64

Linux Distribution Compatibility & Considerations
=================================================

The following table lists Linux distributions that are known to work
well with Cilium. Some distributions require a few initial tweaks. Please make
sure to read each distribution's specific notes below before attempting to
run Cilium.

========================== ====================
Distribution               Minimum Version
========================== ====================
`Amazon Linux 2`_          all
`Bottlerocket OS`_         all
`CentOS`_                  >= 8.6
`Container-Optimized OS`_  >= 85
Debian_                    >= 10 Buster
`Fedora CoreOS`_           >= 31.20200108.3.0
Flatcar_                   all
LinuxKit_                  all
Opensuse_                  Tumbleweed, >=Leap 15.4
`RedHat Enterprise Linux`_ >= 8.6
`RedHat CoreOS`_           >= 4.12
`Talos Linux`_             >= 1.5.0
Ubuntu_                    >= 20.04
========================== ====================

.. _Amazon Linux 2: https://docs.aws.amazon.com/AL2/latest/relnotes/relnotes-al2.html
.. _CentOS: https://centos.org
.. _Container-Optimized OS: https://cloud.google.com/container-optimized-os/docs
.. _Fedora CoreOS: https://fedoraproject.org/coreos/release-notes
.. _Debian: https://www.debian.org/releases/
.. _Flatcar: https://www.flatcar.org/releases
.. _LinuxKit: https://github.com/linuxkit/linuxkit/tree/master/kernel
.. _RedHat Enterprise Linux: https://www.redhat.com/en/technologies/linux-platforms/enterprise-linux
.. _RedHat CoreOS: https://access.redhat.com/articles/6907891
.. _Ubuntu: https://www.releases.ubuntu.com/
.. _Opensuse: https://en.opensuse.org/openSUSE:Roadmap
.. _Bottlerocket OS: https://github.com/bottlerocket-os/bottlerocket
.. _Talos Linux: https://www.talos.dev/

.. note:: The above list is based on feedback by users. If you find an unlisted
          Linux distribution that works well, please let us know by opening a
          GitHub issue or by creating a pull request that updates this guide.

Flatcar on AWS EKS in ENI mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Flatcar is known to manipulate network interfaces created and managed by
Cilium. When running the official Flatcar image for AWS EKS nodes in ENI
mode, this may cause connectivity issues and potentially prevent the Cilium
agent from booting. To avoid this, disable DHCP on the ENI interfaces and mark
them as unmanaged by adding

.. code-block:: text

        [Match]
        Name=eth[1-9]*

        [Network]
        DHCP=no

        [Link]
        Unmanaged=yes

to ``/etc/systemd/network/01-no-dhcp.network`` and then

.. code-block:: shell-session

        systemctl daemon-reload
        systemctl restart systemd-networkd

Ubuntu 22.04 on Raspberry Pi
~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Before running Cilium on Ubuntu 22.04 on a Raspberry Pi, please make sure to install the following package:

.. code-block:: shell-session

        sudo apt install linux-modules-extra-raspi

.. _admin_kernel_version:

Linux Kernel
============

Base Requirements
~~~~~~~~~~~~~~~~~

Cilium leverages and builds on the kernel eBPF functionality as well as various
subsystems which integrate with eBPF. Therefore, host systems are required to
run a recent Linux kernel to run a Cilium agent. More recent kernels may
provide additional eBPF functionality that Cilium will automatically detect and
use on agent start. For this version of Cilium, it is recommended to use kernel
5.4 or later (or equivalent such as 4.18 on RHEL8). For a list of features
that require newer kernels, see :ref:`advanced_features`.

In order for the eBPF feature to be enabled properly, the following kernel
configuration options must be enabled. This is typically the case with
distribution kernels. When an option can be built as a module or statically
linked, either choice is valid.

::

        CONFIG_BPF=y
        CONFIG_BPF_SYSCALL=y
        CONFIG_NET_CLS_BPF=y
        CONFIG_BPF_JIT=y
        CONFIG_NET_CLS_ACT=y
        CONFIG_NET_SCH_INGRESS=y
        CONFIG_CRYPTO_SHA1=y
        CONFIG_CRYPTO_USER_API_HASH=y
        CONFIG_CGROUPS=y
        CONFIG_CGROUP_BPF=y
        CONFIG_PERF_EVENTS=y
        CONFIG_SCHEDSTATS=y

Requirements for Iptables-based Masquerading
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you are not using BPF for masquerading (``enable-bpf-masquerade=false``, the
default value), then you will need the following kernel configuration options.

::

        CONFIG_NETFILTER_XT_SET=m
        CONFIG_IP_SET=m
        CONFIG_IP_SET_HASH_IP=m

Requirements for L7 and FQDN Policies
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

L7 proxy redirection currently uses ``TPROXY`` iptables actions as well
as ``socket`` matches. For L7 redirection to work as intended kernel
configuration must include the following modules:

::

        CONFIG_NETFILTER_XT_TARGET_TPROXY=m
        CONFIG_NETFILTER_XT_TARGET_MARK=m
        CONFIG_NETFILTER_XT_TARGET_CT=m
        CONFIG_NETFILTER_XT_MATCH_MARK=m
        CONFIG_NETFILTER_XT_MATCH_SOCKET=m

When ``xt_socket`` kernel module is missing the forwarding of
redirected L7 traffic does not work in non-tunneled datapath
modes. Since some notable kernels (e.g., COS) are shipping without
``xt_socket`` module, Cilium implements a fallback compatibility mode
to allow L7 policies and visibility to be used with those
kernels. Currently this fallback disables ``ip_early_demux`` kernel
feature in non-tunneled datapath modes, which may decrease system
networking performance. This guarantees HTTP and Kafka redirection
works as intended.  However, if HTTP or Kafka enforcement policies are
never used, this behavior can be turned off by adding the following to
the helm configuration command line:

.. parsed-literal::

   helm install cilium |CHART_RELEASE| \\
     ...
     --set enableXTSocketFallback=false

.. _features_kernel_matrix:

Requirements for IPsec
~~~~~~~~~~~~~~~~~~~~~~

The :ref:`encryption_ipsec` feature requires a lot of kernel configuration
options, most of which to enable the actual encryption. Note that the
specific options required depend on the algorithm. The list below
corresponds to requirements for GCM-128-AES.

::

        CONFIG_XFRM=y
        CONFIG_XFRM_OFFLOAD=y
        CONFIG_XFRM_STATISTICS=y
        CONFIG_XFRM_ALGO=m
        CONFIG_XFRM_USER=m
        CONFIG_INET{,6}_ESP=m
        CONFIG_INET{,6}_IPCOMP=m
        CONFIG_INET{,6}_XFRM_TUNNEL=m
        CONFIG_INET{,6}_TUNNEL=m
        CONFIG_INET_XFRM_MODE_TUNNEL=m
        CONFIG_CRYPTO_AEAD=m
        CONFIG_CRYPTO_AEAD2=m
        CONFIG_CRYPTO_GCM=m
        CONFIG_CRYPTO_SEQIV=m
        CONFIG_CRYPTO_CBC=m
        CONFIG_CRYPTO_HMAC=m
        CONFIG_CRYPTO_SHA256=m
        CONFIG_CRYPTO_AES=m

Requirements for the Bandwidth Manager
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The :ref:`bandwidth-manager` requires the following kernel configuration option
to change the packet scheduling algorithm.

::

        CONFIG_NET_SCH_FQ=m

Requirements for Netkit Device Mode
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The :ref:`netkit` requires the following kernel configuration option
to create netkit devices.

::

        CONFIG_NETKIT=y

.. _advanced_features:

Required Kernel Versions for Advanced Features
==============================================

Additional kernel features continues to progress in the Linux community. Some
of Cilium's features are dependent on newer kernel versions and are thus
enabled by upgrading to more recent kernel versions as detailed below.

====================================================== ===============================
Cilium Feature                                         Minimum Kernel Version
====================================================== ===============================
:ref:`encryption_wg`                                   >= 5.6
Full support for :ref:`session-affinity`               >= 5.7
BPF-based proxy redirection                            >= 5.7
Socket-level LB bypass in pod netns                    >= 5.7
L3 devices                                             >= 5.8
BPF-based host routing                                 >= 5.10
:ref:`enable_multicast` (AMD64)                        >= 5.10
IPv6 BIG TCP support                                   >= 5.19
:ref:`enable_multicast` (AArch64)                      >= 6.0
IPv4 BIG TCP support                                   >= 6.3
====================================================== ===============================

.. _req_kvstore:

Key-Value store
===============

Cilium optionally uses a distributed Key-Value store to manage,
synchronize and distribute security identities across all cluster
nodes. The following Key-Value stores are currently supported:

- etcd >= 3.1.0

Cilium can be used without a Key-Value store when CRD-based state
management is used with Kubernetes. This is the default for new Cilium
installations. Larger clusters will perform better with a Key-Value
store backed identity management instead, see :ref:`k8s_quick_install`
for more details.

See :ref:`install_kvstore` for details on how to configure the
``cilium-agent`` to use a Key-Value store.

clang+LLVM
==========

.. note:: This requirement is only needed if you run ``cilium-agent`` natively.
          If you are using the Cilium container image ``cilium/cilium``,
          clang+LLVM is included in the container image.

LLVM is the compiler suite that Cilium uses to generate eBPF bytecode programs
to be loaded into the Linux kernel. The minimum supported version of LLVM
available to ``cilium-agent`` should be >=5.0. The version of clang installed
must be compiled with the eBPF backend enabled.

See https://releases.llvm.org/ for information on how to download and install
LLVM.

.. _firewall_requirements:

Firewall Rules
==============

If you are running Cilium in an environment that requires firewall rules to
enable connectivity, you will have to add the following rules to ensure Cilium
works properly.

It is recommended but optional that all nodes running Cilium in a given cluster
must be able to ping each other so ``cilium-health`` can report and monitor
connectivity among nodes. This requires ICMP Type 0/8, Code 0 open among all
nodes. TCP 4240 should also be open among all nodes for ``cilium-health``
monitoring. Note that it is also an option to only use one of these two methods
to enable health monitoring. If the firewall does not permit either of these
methods, Cilium will still operate fine but will not be able to provide health
information.

For IPsec enabled Cilium deployments, you need to ensure that the firewall
allows ESP traffic through. For example, AWS Security Groups doesn't allow ESP
traffic by default.

If you are using WireGuard, you must allow UDP port 51871.

If you are using VXLAN overlay network mode, Cilium uses Linux's default VXLAN
port 8472 over UDP, unless Linux has been configured otherwise. In this case,
UDP 8472 must be open among all nodes to enable VXLAN overlay mode. The same
applies to Geneve overlay network mode, except the port is UDP 6081.

If you are running in direct routing mode, your network must allow routing of
pod IPs.

As an example, if you are running on AWS with VXLAN overlay networking, here is
a minimum set of AWS Security Group (SG) rules. It assumes a separation between
the SG on the master nodes, ``master-sg``, and the worker nodes, ``worker-sg``.
It also assumes ``etcd`` is running on the master nodes.

Master Nodes (``master-sg``) Rules:

======================== =============== ==================== ===============
Port Range / Protocol    Ingress/Egress  Source/Destination   Description
======================== =============== ==================== ===============
2379-2380/tcp            ingress         ``worker-sg``        etcd access
8472/udp                 ingress         ``master-sg`` (self) VXLAN overlay
8472/udp                 ingress         ``worker-sg``        VXLAN overlay
4240/tcp                 ingress         ``master-sg`` (self) health checks
4240/tcp                 ingress         ``worker-sg``        health checks
ICMP 8/0                 ingress         ``master-sg`` (self) health checks
ICMP 8/0                 ingress         ``worker-sg``        health checks
8472/udp                 egress          ``master-sg`` (self) VXLAN overlay
8472/udp                 egress          ``worker-sg``        VXLAN overlay
4240/tcp                 egress          ``master-sg`` (self) health checks
4240/tcp                 egress          ``worker-sg``        health checks
ICMP 8/0                 egress          ``master-sg`` (self) health checks
ICMP 8/0                 egress          ``worker-sg``        health checks
======================== =============== ==================== ===============

Worker Nodes (``worker-sg``):

======================== =============== ==================== ===============
Port Range / Protocol    Ingress/Egress  Source/Destination   Description
======================== =============== ==================== ===============
8472/udp                 ingress         ``master-sg``        VXLAN overlay
8472/udp                 ingress         ``worker-sg`` (self) VXLAN overlay
4240/tcp                 ingress         ``master-sg``        health checks
4240/tcp                 ingress         ``worker-sg`` (self) health checks
ICMP 8/0                 ingress         ``master-sg``        health checks
ICMP 8/0                 ingress         ``worker-sg`` (self) health checks
8472/udp                 egress          ``master-sg``        VXLAN overlay
8472/udp                 egress          ``worker-sg`` (self) VXLAN overlay
4240/tcp                 egress          ``master-sg``        health checks
4240/tcp                 egress          ``worker-sg`` (self) health checks
ICMP 8/0                 egress          ``master-sg``        health checks
ICMP 8/0                 egress          ``worker-sg`` (self) health checks
2379-2380/tcp            egress          ``master-sg``        etcd access
======================== =============== ==================== ===============

.. note:: If you use a shared SG for the masters and workers, you can condense
          these rules into ingress/egress to self. If you are using Direct
          Routing mode, you can condense all rules into ingress/egress ANY
          port/protocol to/from self.

The following ports should also be available on each node:

======================== ==================================================================
Port Range / Protocol    Description
======================== ==================================================================
4240/tcp                 cluster health checks (``cilium-health``)
4244/tcp                 Hubble server
4245/tcp                 Hubble Relay
4250/tcp                 Mutual Authentication port
4251/tcp                 Spire Agent health check port (listening on 127.0.0.1 or ::1)
6060/tcp                 cilium-agent pprof server (listening on 127.0.0.1)
6061/tcp                 cilium-operator pprof server (listening on 127.0.0.1)
6062/tcp                 Hubble Relay pprof server (listening on 127.0.0.1)
9878/tcp                 cilium-envoy health listener (listening on 127.0.0.1)
9879/tcp                 cilium-agent health status API (listening on 127.0.0.1 and/or ::1)
9890/tcp                 cilium-agent gops server (listening on 127.0.0.1)
9891/tcp                 operator gops server (listening on 127.0.0.1)
9893/tcp                 Hubble Relay gops server (listening on 127.0.0.1)
9901/tcp                 cilium-envoy Admin API (listening on 127.0.0.1)
9962/tcp                 cilium-agent Prometheus metrics
9963/tcp                 cilium-operator Prometheus metrics
9964/tcp                 cilium-envoy Prometheus metrics
51871/udp                WireGuard encryption tunnel endpoint
======================== ==================================================================

.. _admin_mount_bpffs:

Mounted eBPF filesystem
=======================

.. Note::

        Some distributions mount the bpf filesystem automatically. Check if the
        bpf filesystem is mounted by running the command.

        .. code-block:: shell-session

            # mount | grep /sys/fs/bpf
            $ # if present should output, e.g. "none on /sys/fs/bpf type bpf"...

If the eBPF filesystem is not mounted in the host filesystem, Cilium will
automatically mount the filesystem.

Mounting this BPF filesystem allows the ``cilium-agent`` to persist eBPF
resources across restarts of the agent so that the datapath can continue to
operate while the agent is subsequently restarted or upgraded.

Optionally it is also possible to mount the eBPF filesystem before Cilium is
deployed in the cluster, the following command must be run in the host mount
namespace. The command must only be run once during the boot process of the
machine.

   .. code-block:: shell-session

	# mount bpffs /sys/fs/bpf -t bpf

A portable way to achieve this with persistence is to add the following line to
``/etc/fstab`` and then run ``mount /sys/fs/bpf``. This will cause the
filesystem to be automatically mounted when the node boots.

::

     bpffs			/sys/fs/bpf		bpf	defaults 0 0

If you are using systemd to manage the kubelet, see the section
:ref:`bpffs_systemd`.

Routing Tables
==============

When running in :ref:`ipam_eni` IPAM mode, Cilium will install per-ENI routing
tables for each ENI that is used by Cilium for pod IP allocation.
These routing tables are added to the host network namespace and must not be
otherwise used by the system.
The index of those per-ENI routing tables is computed as
``10 + <eni-interface-index>``. The base offset of 10 is chosen as it is highly
unlikely to collide with the main routing table which is between 253-255.

Privileges
==========

The following privileges are required to run Cilium. When running the standard
Kubernetes :term:`DaemonSet`, the privileges are automatically granted to Cilium.

* Cilium interacts with the Linux kernel to install eBPF program which will then
  perform networking tasks and implement security rules. In order to install
  eBPF programs system-wide, ``CAP_SYS_ADMIN`` privileges are required. These
  privileges must be granted to ``cilium-agent``.

  The quickest way to meet the requirement is to run ``cilium-agent`` as root
  and/or as privileged container.

* Cilium requires access to the host networking namespace. For this purpose,
  the Cilium pod is scheduled to run in the host networking namespace directly.

only   not  epub or latex or html       WARNING  You are looking at unreleased Cilium documentation      Please use the official rendered version released here      https   docs cilium io      admin system reqs                       System Requirements                      Before installing Cilium  please ensure that your system meets the minimum requirements below  Most modern Linux distributions already do   Summary          When running Cilium using the container image   cilium cilium    the host system must meet these requirements     Hosts with either AMD64 or AArch64 architecture    Linux kernel      5 4 or equivalent  e g   4 18 on RHEL 8 6   When running Cilium as a native process on your host  i e    not   running the   cilium cilium   container image  these additional requirements must be met      clang LLVM      10 0       clang LLVM   https   llvm org  When running Cilium without Kubernetes these additional requirements must be met      ref  req kvstore  etcd    3 1 0                                                                              Requirement              Minimum Version                In cilium container                                                                              Linux kernel               5 4 or    4 18 on RHEL 8 6  no Key Value store  etcd       3 1 0                       no clang LLVM                  10 0                        yes                                                                              Architecture Support                       Cilium images are built for the following platforms     AMD64   AArch64  Linux Distribution Compatibility   Considerations                                                    The following table lists Linux distributions that are known to work well with Cilium  Some distributions require a few initial tweaks  Please make sure to read each distribution s specific notes below before attempting to run Cilium                                                   Distribution               Minimum Version                                                  Amazon Linux 2            all  Bottlerocket OS           all  CentOS                       8 6  Container Optimized OS       85 Debian                        10 Buster  Fedora CoreOS                31 20200108 3 0 Flatcar                    all LinuxKit                   all Opensuse                   Tumbleweed    Leap 15 4  RedHat Enterprise Linux      8 6  RedHat CoreOS                4 12  Talos Linux                  1 5 0 Ubuntu                        20 04                                                      Amazon Linux 2  https   docs aws amazon com AL2 latest relnotes relnotes al2 html     CentOS  https   centos org     Container Optimized OS  https   cloud google com container optimized os docs     Fedora CoreOS  https   fedoraproject org coreos release notes     Debian  https   www debian org releases      Flatcar  https   www flatcar org releases     LinuxKit  https   github com linuxkit linuxkit tree master kernel     RedHat Enterprise Linux  https   www redhat com en technologies linux platforms enterprise linux     RedHat CoreOS  https   access redhat com articles 6907891     Ubuntu  https   www releases ubuntu com      Opensuse  https   en opensuse org openSUSE Roadmap     Bottlerocket OS  https   github com bottlerocket os bottlerocket     Talos Linux  https   www talos dev      note   The above list is based on feedback by users  If you find an unlisted           Linux distribution that works well  please let us know by opening a           GitHub issue or by creating a pull request that updates this guide    Flatcar on AWS EKS in ENI mode                                 Flatcar is known to manipulate network interfaces created and managed by Cilium  When running the official Flatcar image for AWS EKS nodes in ENI mode  this may cause connectivity issues and potentially prevent the Cilium agent from booting  To avoid this  disable DHCP on the ENI interfaces and mark them as unmanaged by adding     code block   text           Match          Name eth 1 9             Network          DHCP no           Link          Unmanaged yes  to    etc systemd network 01 no dhcp network   and then     code block   shell session          systemctl daemon reload         systemctl restart systemd networkd  Ubuntu 22 04 on Raspberry Pi                               Before running Cilium on Ubuntu 22 04 on a Raspberry Pi  please make sure to install the following package      code block   shell session          sudo apt install linux modules extra raspi      admin kernel version   Linux Kernel               Base Requirements                    Cilium leverages and builds on the kernel eBPF functionality as well as various subsystems which integrate with eBPF  Therefore  host systems are required to run a recent Linux kernel to run a Cilium agent  More recent kernels may provide additional eBPF functionality that Cilium will automatically detect and use on agent start  For this version of Cilium  it is recommended to use kernel 5 4 or later  or equivalent such as 4 18 on RHEL8   For a list of features that require newer kernels  see  ref  advanced features    In order for the eBPF feature to be enabled properly  the following kernel configuration options must be enabled  This is typically the case with distribution kernels  When an option can be built as a module or statically linked  either choice is valid               CONFIG BPF y         CONFIG BPF SYSCALL y         CONFIG NET CLS BPF y         CONFIG BPF JIT y         CONFIG NET CLS ACT y         CONFIG NET SCH INGRESS y         CONFIG CRYPTO SHA1 y         CONFIG CRYPTO USER API HASH y         CONFIG CGROUPS y         CONFIG CGROUP BPF y         CONFIG PERF EVENTS y         CONFIG SCHEDSTATS y   Requirements for Iptables based Masquerading                                               If you are not using BPF for masquerading    enable bpf masquerade false    the default value   then you will need the following kernel configuration options               CONFIG NETFILTER XT SET m         CONFIG IP SET m         CONFIG IP SET HASH IP m  Requirements for L7 and FQDN Policies                                        L7 proxy redirection currently uses   TPROXY   iptables actions as well as   socket   matches  For L7 redirection to work as intended kernel configuration must include the following modules               CONFIG NETFILTER XT TARGET TPROXY m         CONFIG NETFILTER XT TARGET MARK m         CONFIG NETFILTER XT TARGET CT m         CONFIG NETFILTER XT MATCH MARK m         CONFIG NETFILTER XT MATCH SOCKET m  When   xt socket   kernel module is missing the forwarding of redirected L7 traffic does not work in non tunneled datapath modes  Since some notable kernels  e g   COS  are shipping without   xt socket   module  Cilium implements a fallback compatibility mode to allow L7 policies and visibility to be used with those kernels  Currently this fallback disables   ip early demux   kernel feature in non tunneled datapath modes  which may decrease system networking performance  This guarantees HTTP and Kafka redirection works as intended   However  if HTTP or Kafka enforcement policies are never used  this behavior can be turned off by adding the following to the helm configuration command line      parsed literal       helm install cilium  CHART RELEASE                     set enableXTSocketFallback false      features kernel matrix   Requirements for IPsec                         The  ref  encryption ipsec  feature requires a lot of kernel configuration options  most of which to enable the actual encryption  Note that the specific options required depend on the algorithm  The list below corresponds to requirements for GCM 128 AES               CONFIG XFRM y         CONFIG XFRM OFFLOAD y         CONFIG XFRM STATISTICS y         CONFIG XFRM ALGO m         CONFIG XFRM USER m         CONFIG INET  6  ESP m         CONFIG INET  6  IPCOMP m         CONFIG INET  6  XFRM TUNNEL m         CONFIG INET  6  TUNNEL m         CONFIG INET XFRM MODE TUNNEL m         CONFIG CRYPTO AEAD m         CONFIG CRYPTO AEAD2 m         CONFIG CRYPTO GCM m         CONFIG CRYPTO SEQIV m         CONFIG CRYPTO CBC m         CONFIG CRYPTO HMAC m         CONFIG CRYPTO SHA256 m         CONFIG CRYPTO AES m  Requirements for the Bandwidth Manager                                         The  ref  bandwidth manager  requires the following kernel configuration option to change the packet scheduling algorithm               CONFIG NET SCH FQ m  Requirements for Netkit Device Mode                                      The  ref  netkit  requires the following kernel configuration option to create netkit devices               CONFIG NETKIT y      advanced features   Required Kernel Versions for Advanced Features                                                 Additional kernel features continues to progress in the Linux community  Some of Cilium s features are dependent on newer kernel versions and are thus enabled by upgrading to more recent kernel versions as detailed below                                                                                Cilium Feature                                         Minimum Kernel Version                                                                                ref  encryption wg                                       5 6 Full support for  ref  session affinity                   5 7 BPF based proxy redirection                               5 7 Socket level LB bypass in pod netns                       5 7 L3 devices                                                5 8 BPF based host routing                                    5 10  ref  enable multicast   AMD64                            5 10 IPv6 BIG TCP support                                      5 19  ref  enable multicast   AArch64                          6 0 IPv4 BIG TCP support                                      6 3                                                                                req kvstore   Key Value store                  Cilium optionally uses a distributed Key Value store to manage  synchronize and distribute security identities across all cluster nodes  The following Key Value stores are currently supported     etcd    3 1 0  Cilium can be used without a Key Value store when CRD based state management is used with Kubernetes  This is the default for new Cilium installations  Larger clusters will perform better with a Key Value store backed identity management instead  see  ref  k8s quick install  for more details   See  ref  install kvstore  for details on how to configure the   cilium agent   to use a Key Value store   clang LLVM                 note   This requirement is only needed if you run   cilium agent   natively            If you are using the Cilium container image   cilium cilium              clang LLVM is included in the container image   LLVM is the compiler suite that Cilium uses to generate eBPF bytecode programs to be loaded into the Linux kernel  The minimum supported version of LLVM available to   cilium agent   should be   5 0  The version of clang installed must be compiled with the eBPF backend enabled   See https   releases llvm org  for information on how to download and install LLVM       firewall requirements   Firewall Rules                 If you are running Cilium in an environment that requires firewall rules to enable connectivity  you will have to add the following rules to ensure Cilium works properly   It is recommended but optional that all nodes running Cilium in a given cluster must be able to ping each other so   cilium health   can report and monitor connectivity among nodes  This requires ICMP Type 0 8  Code 0 open among all nodes  TCP 4240 should also be open among all nodes for   cilium health   monitoring  Note that it is also an option to only use one of these two methods to enable health monitoring  If the firewall does not permit either of these methods  Cilium will still operate fine but will not be able to provide health information   For IPsec enabled Cilium deployments  you need to ensure that the firewall allows ESP traffic through  For example  AWS Security Groups doesn t allow ESP traffic by default   If you are using WireGuard  you must allow UDP port 51871   If you are using VXLAN overlay network mode  Cilium uses Linux s default VXLAN port 8472 over UDP  unless Linux has been configured otherwise  In this case  UDP 8472 must be open among all nodes to enable VXLAN overlay mode  The same applies to Geneve overlay network mode  except the port is UDP 6081   If you are running in direct routing mode  your network must allow routing of pod IPs   As an example  if you are running on AWS with VXLAN overlay networking  here is a minimum set of AWS Security Group  SG  rules  It assumes a separation between the SG on the master nodes    master sg    and the worker nodes    worker sg    It also assumes   etcd   is running on the master nodes   Master Nodes    master sg    Rules                                                                                Port Range   Protocol    Ingress Egress  Source Destination   Description                                                                               2379 2380 tcp            ingress           worker sg          etcd access 8472 udp                 ingress           master sg    self  VXLAN overlay 8472 udp                 ingress           worker sg          VXLAN overlay 4240 tcp                 ingress           master sg    self  health checks 4240 tcp                 ingress           worker sg          health checks ICMP 8 0                 ingress           master sg    self  health checks ICMP 8 0                 ingress           worker sg          health checks 8472 udp                 egress            master sg    self  VXLAN overlay 8472 udp                 egress            worker sg          VXLAN overlay 4240 tcp                 egress            master sg    self  health checks 4240 tcp                 egress            worker sg          health checks ICMP 8 0                 egress            master sg    self  health checks ICMP 8 0                 egress            worker sg          health checks                                                                                Worker Nodes    worker sg                                                                                Port Range   Protocol    Ingress Egress  Source Destination   Description                                                                               8472 udp                 ingress           master sg          VXLAN overlay 8472 udp                 ingress           worker sg    self  VXLAN overlay 4240 tcp                 ingress           master sg          health checks 4240 tcp                 ingress           worker sg    self  health checks ICMP 8 0                 ingress           master sg          health checks ICMP 8 0                 ingress           worker sg    self  health checks 8472 udp                 egress            master sg          VXLAN overlay 8472 udp                 egress            worker sg    self  VXLAN overlay 4240 tcp                 egress            master sg          health checks 4240 tcp                 egress            worker sg    self  health checks ICMP 8 0                 egress            master sg          health checks ICMP 8 0                 egress            worker sg    self  health checks 2379 2380 tcp            egress            master sg          etcd access                                                                                note   If you use a shared SG for the masters and workers  you can condense           these rules into ingress egress to self  If you are using Direct           Routing mode  you can condense all rules into ingress egress ANY           port protocol to from self   The following ports should also be available on each node                                                                                Port Range   Protocol    Description                                                                                4240 tcp                 cluster health checks    cilium health    4244 tcp                 Hubble server 4245 tcp                 Hubble Relay 4250 tcp                 Mutual Authentication port 4251 tcp                 Spire Agent health check port  listening on 127 0 0 1 or   1  6060 tcp                 cilium agent pprof server  listening on 127 0 0 1  6061 tcp                 cilium operator pprof server  listening on 127 0 0 1  6062 tcp                 Hubble Relay pprof server  listening on 127 0 0 1  9878 tcp                 cilium envoy health listener  listening on 127 0 0 1  9879 tcp                 cilium agent health status API  listening on 127 0 0 1 and or   1  9890 tcp                 cilium agent gops server  listening on 127 0 0 1  9891 tcp                 operator gops server  listening on 127 0 0 1  9893 tcp                 Hubble Relay gops server  listening on 127 0 0 1  9901 tcp                 cilium envoy Admin API  listening on 127 0 0 1  9962 tcp                 cilium agent Prometheus metrics 9963 tcp                 cilium operator Prometheus metrics 9964 tcp                 cilium envoy Prometheus metrics 51871 udp                WireGuard encryption tunnel endpoint                                                                                admin mount bpffs   Mounted eBPF filesystem                             Note            Some distributions mount the bpf filesystem automatically  Check if the         bpf filesystem is mounted by running the command              code block   shell session                mount   grep  sys fs bpf                 if present should output  e g   none on  sys fs bpf type bpf      If the eBPF filesystem is not mounted in the host filesystem  Cilium will automatically mount the filesystem   Mounting this BPF filesystem allows the   cilium agent   to persist eBPF resources across restarts of the agent so that the datapath can continue to operate while the agent is subsequently restarted or upgraded   Optionally it is also possible to mount the eBPF filesystem before Cilium is deployed in the cluster  the following command must be run in the host mount namespace  The command must only be run once during the boot process of the machine         code block   shell session     mount bpffs  sys fs bpf  t bpf  A portable way to achieve this with persistence is to add the following line to    etc fstab   and then run   mount  sys fs bpf    This will cause the filesystem to be automatically mounted when the node boots            bpffs    sys fs bpf  bpf defaults 0 0  If you are using systemd to manage the kubelet  see the section  ref  bpffs systemd    Routing Tables                 When running in  ref  ipam eni  IPAM mode  Cilium will install per ENI routing tables for each ENI that is used by Cilium for pod IP allocation  These routing tables are added to the host network namespace and must not be otherwise used by the system  The index of those per ENI routing tables is computed as   10    eni interface index     The base offset of 10 is chosen as it is highly unlikely to collide with the main routing table which is between 253 255   Privileges             The following privileges are required to run Cilium  When running the standard Kubernetes  term  DaemonSet   the privileges are automatically granted to Cilium     Cilium interacts with the Linux kernel to install eBPF program which will then   perform networking tasks and implement security rules  In order to install   eBPF programs system wide    CAP SYS ADMIN   privileges are required  These   privileges must be granted to   cilium agent       The quickest way to meet the requirement is to run   cilium agent   as root   and or as privileged container     Cilium requires access to the host networking namespace  For this purpose    the Cilium pod is scheduled to run in the host networking namespace directly


cilium docs cilium io This document serves as an introduction for using Cilium to enforce DNS based Locking Down External Access with DNS Based Policies security policies for Kubernetes pods gsdns

Answer:
.. only:: not (epub or latex or html)

    WARNING: You are looking at unreleased Cilium documentation.
    Please use the official rendered version released here:
    https://docs.cilium.io

.. _gs_dns:

****************************************************
Locking Down External Access with DNS-Based Policies
****************************************************

This document serves as an introduction for using Cilium to enforce DNS-based
security policies for Kubernetes pods.

.. include:: gsg_requirements.rst

Deploy the Demo Application
===========================

DNS-based policies are very useful for controlling access to services running outside the Kubernetes cluster. DNS acts as a persistent service identifier for both external services provided by AWS, Google, Twilio, Stripe, etc., and internal services such as database clusters running in private subnets outside Kubernetes. CIDR or IP-based policies are cumbersome and hard to maintain as the IPs associated with external services can change frequently. The Cilium DNS-based policies provide an easy mechanism to specify access control while Cilium manages the harder aspects of tracking DNS to IP mapping.

In this guide we will learn about:

- Controlling egress access to services outside the cluster using DNS-based policies
- Using patterns (or wildcards) to whitelist a subset of DNS domains
- Combining DNS, port and L7 rules for restricting access to external service

In line with our Star Wars theme examples, we will use a simple scenario where
the Empire's ``mediabot`` pods need access to GitHub for managing the Empire's
git repositories. The pods shouldn't have access to any other external service.

.. parsed-literal::

   $ kubectl create -f \ |SCM_WEB|\/examples/kubernetes-dns/dns-sw-app.yaml
   $ kubectl wait pod/mediabot --for=condition=Ready
   $ kubectl get pods
   NAME                             READY   STATUS    RESTARTS   AGE
   pod/mediabot                     1/1     Running   0          14s

Apply DNS Egress Policy
=======================

The following Cilium network policy allows ``mediabot`` pods to only access ``api.github.com``.

.. tabs::

   .. group-tab:: Generic

      .. literalinclude:: ../../examples/kubernetes-dns/dns-matchname.yaml

   .. group-tab:: OpenShift

      .. literalinclude:: ../../examples/kubernetes-dns/dns-matchname-openshift.yaml

.. note::

   OpenShift users will need to modify the policies to match the namespace
   ``openshift-dns`` (instead of ``kube-system``), remove the match on the
   ``k8s:k8s-app=kube-dns`` label, and change the port to 5353.

Let's take a closer look at the policy:

* The first egress section uses ``toFQDNs: matchName`` specification to allow
  egress to ``api.github.com``. The destination DNS should match exactly the
  name specified in the rule. The ``endpointSelector`` allows only pods with
  labels ``class: mediabot, org:empire`` to have the egress access.
* The second egress section (``toEndpoints``) allows ``mediabot`` pods to access
  ``kube-dns`` service. Note that ``rules: dns`` instructs Cilium to inspect and
  allow DNS lookups matching specified patterns. In this case, inspect and allow
  all DNS queries.

Note that with this policy the ``mediabot`` doesn't have access to any internal
cluster service other than ``kube-dns``. Refer to :ref:`Network Policy` to learn
more about policies for controlling access to internal cluster services.

Let's apply the policy:

.. parsed-literal::

  kubectl apply -f \ |SCM_WEB|\/examples/kubernetes-dns/dns-matchname.yaml

Testing the policy, we see that ``mediabot`` has access to ``api.github.com``
but doesn't have access to any other external service, e.g.,
``support.github.com``.

.. code-block:: shell-session

   $ kubectl exec mediabot -- curl -I -s https://api.github.com | head -1
   HTTP/2 200

   $ kubectl exec mediabot -- curl -I -s --max-time 5 https://support.github.com | head -1
   curl: (28) Connection timed out after 5000 milliseconds
   command terminated with exit code 28

DNS Policies Using Patterns
===========================

The above policy controlled DNS access based on exact match of the DNS domain
name. Often, it is required to allow access to a subset of domains. Let's say,
in the above example, ``mediabot`` pods need access to any GitHub sub-domain,
e.g., the pattern ``*.github.com``. We can achieve this easily by changing the
``toFQDN`` rule to use ``matchPattern`` instead of ``matchName``.

.. literalinclude:: ../../examples/kubernetes-dns/dns-pattern.yaml

.. parsed-literal::

   kubectl apply -f \ |SCM_WEB|\/examples/kubernetes-dns/dns-pattern.yaml

Test that ``mediabot`` has access to multiple GitHub services for which the DNS
matches the pattern ``*.github.com``. It is important to note and test that this
doesn't allow access to ``github.com`` because the ``*.`` in the pattern
requires one subdomain to be present in the DNS name. You can simply add more
``matchName`` and ``matchPattern`` clauses to extend the access. (See :ref:`DNS based`
policies to learn more about specifying DNS rules using patterns and names.)

.. code-block:: shell-session

   $ kubectl exec mediabot -- curl -I -s https://support.github.com | head -1
   HTTP/1.1 200 OK

   $ kubectl exec mediabot -- curl -I -s https://gist.github.com | head -1
   HTTP/1.1 302 Found

   $ kubectl exec mediabot -- curl -I -s --max-time 5 https://github.com | head -1
   curl: (28) Connection timed out after 5000 milliseconds
   command terminated with exit code 28

Combining DNS, Port and L7 Rules
================================

The DNS-based policies can be combined with port (L4) and API (L7) rules to
further restrict the access. In our example, we will restrict ``mediabot`` pods
to access GitHub services only on ports ``443``. The ``toPorts`` section in the
policy below achieves the port-based restrictions along with the DNS-based
policies.

.. literalinclude:: ../../examples/kubernetes-dns/dns-port.yaml

.. parsed-literal::

  kubectl apply -f \ |SCM_WEB|\/examples/kubernetes-dns/dns-port.yaml

Testing, the access to ``https://support.github.com`` on port ``443`` will
succeed but the access to ``http://support.github.com`` on port ``80`` will be
denied.

.. code-block:: shell-session

   $ kubectl exec mediabot -- curl -I -s https://support.github.com | head -1
   HTTP/1.1 200 OK

   $ kubectl exec mediabot -- curl -I -s --max-time 5 http://support.github.com | head -1
   curl: (28) Connection timed out after 5001 milliseconds
   command terminated with exit code 28

Refer to :ref:`l4_policy` and :ref:`l7_policy` to learn more about Cilium L4 and
L7 network policies.

Clean-up
========

.. parsed-literal::

   kubectl delete -f \ |SCM_WEB|\/examples/kubernetes-dns/dns-sw-app.yaml
   kubectl delete cnp fqdn

only   not  epub or latex or html       WARNING  You are looking at unreleased Cilium documentation      Please use the official rendered version released here      https   docs cilium io      gs dns                                                        Locking Down External Access with DNS Based Policies                                                       This document serves as an introduction for using Cilium to enforce DNS based security policies for Kubernetes pods      include   gsg requirements rst  Deploy the Demo Application                              DNS based policies are very useful for controlling access to services running outside the Kubernetes cluster  DNS acts as a persistent service identifier for both external services provided by AWS  Google  Twilio  Stripe  etc   and internal services such as database clusters running in private subnets outside Kubernetes  CIDR or IP based policies are cumbersome and hard to maintain as the IPs associated with external services can change frequently  The Cilium DNS based policies provide an easy mechanism to specify access control while Cilium manages the harder aspects of tracking DNS to IP mapping   In this guide we will learn about     Controlling egress access to services outside the cluster using DNS based policies   Using patterns  or wildcards  to whitelist a subset of DNS domains   Combining DNS  port and L7 rules for restricting access to external service  In line with our Star Wars theme examples  we will use a simple scenario where the Empire s   mediabot   pods need access to GitHub for managing the Empire s git repositories  The pods shouldn t have access to any other external service      parsed literal         kubectl create  f    SCM WEB   examples kubernetes dns dns sw app yaml      kubectl wait pod mediabot   for condition Ready      kubectl get pods    NAME                             READY   STATUS    RESTARTS   AGE    pod mediabot                     1 1     Running   0          14s   Apply DNS Egress Policy                          The following Cilium network policy allows   mediabot   pods to only access   api github com        tabs          group tab   Generic           literalinclude         examples kubernetes dns dns matchname yaml        group tab   OpenShift           literalinclude         examples kubernetes dns dns matchname openshift yaml     note       OpenShift users will need to modify the policies to match the namespace      openshift dns    instead of   kube system     remove the match on the      k8s k8s app kube dns   label  and change the port to 5353   Let s take a closer look at the policy     The first egress section uses   toFQDNs  matchName   specification to allow   egress to   api github com    The destination DNS should match exactly the   name specified in the rule  The   endpointSelector   allows only pods with   labels   class  mediabot  org empire   to have the egress access    The second egress section    toEndpoints    allows   mediabot   pods to access     kube dns   service  Note that   rules  dns   instructs Cilium to inspect and   allow DNS lookups matching specified patterns  In this case  inspect and allow   all DNS queries   Note that with this policy the   mediabot   doesn t have access to any internal cluster service other than   kube dns    Refer to  ref  Network Policy  to learn more about policies for controlling access to internal cluster services   Let s apply the policy      parsed literal      kubectl apply  f    SCM WEB   examples kubernetes dns dns matchname yaml  Testing the policy  we see that   mediabot   has access to   api github com   but doesn t have access to any other external service  e g     support github com        code block   shell session       kubectl exec mediabot    curl  I  s https   api github com   head  1    HTTP 2 200       kubectl exec mediabot    curl  I  s   max time 5 https   support github com   head  1    curl   28  Connection timed out after 5000 milliseconds    command terminated with exit code 28  DNS Policies Using Patterns                              The above policy controlled DNS access based on exact match of the DNS domain name  Often  it is required to allow access to a subset of domains  Let s say  in the above example    mediabot   pods need access to any GitHub sub domain  e g   the pattern     github com    We can achieve this easily by changing the   toFQDN   rule to use   matchPattern   instead of   matchName        literalinclude         examples kubernetes dns dns pattern yaml     parsed literal       kubectl apply  f    SCM WEB   examples kubernetes dns dns pattern yaml  Test that   mediabot   has access to multiple GitHub services for which the DNS matches the pattern     github com    It is important to note and test that this doesn t allow access to   github com   because the        in the pattern requires one subdomain to be present in the DNS name  You can simply add more   matchName   and   matchPattern   clauses to extend the access   See  ref  DNS based  policies to learn more about specifying DNS rules using patterns and names       code block   shell session       kubectl exec mediabot    curl  I  s https   support github com   head  1    HTTP 1 1 200 OK       kubectl exec mediabot    curl  I  s https   gist github com   head  1    HTTP 1 1 302 Found       kubectl exec mediabot    curl  I  s   max time 5 https   github com   head  1    curl   28  Connection timed out after 5000 milliseconds    command terminated with exit code 28  Combining DNS  Port and L7 Rules                                   The DNS based policies can be combined with port  L4  and API  L7  rules to further restrict the access  In our example  we will restrict   mediabot   pods to access GitHub services only on ports   443    The   toPorts   section in the policy below achieves the port based restrictions along with the DNS based policies      literalinclude         examples kubernetes dns dns port yaml     parsed literal      kubectl apply  f    SCM WEB   examples kubernetes dns dns port yaml  Testing  the access to   https   support github com   on port   443   will succeed but the access to   http   support github com   on port   80   will be denied      code block   shell session       kubectl exec mediabot    curl  I  s https   support github com   head  1    HTTP 1 1 200 OK       kubectl exec mediabot    curl  I  s   max time 5 http   support github com   head  1    curl   28  Connection timed out after 5001 milliseconds    command terminated with exit code 28  Refer to  ref  l4 policy  and  ref  l7 policy  to learn more about Cilium L4 and L7 network policies   Clean up              parsed literal       kubectl delete  f    SCM WEB   examples kubernetes dns dns sw app yaml    kubectl delete cnp fqdn


cilium Host Firewall docs cilium io hostfirewall security policies for Kubernetes nodes This document serves as an introduction to Cilium s host firewall to enforce

Answer:
.. only:: not (epub or latex or html)

    WARNING: You are looking at unreleased Cilium documentation.
    Please use the official rendered version released here:
    https://docs.cilium.io

.. _host_firewall:

*************
Host Firewall
*************

This document serves as an introduction to Cilium's host firewall, to enforce
security policies for Kubernetes nodes.

.. admonition:: Video
  :class: attention

  You can also watch a video of Cilium's host firewall in action on
  `eCHO Episode 40: Cilium Host Firewall <https://www.youtube.com/watch?v=GLLLcz398K0&t=288s>`__.

Enable the Host Firewall in Cilium
==================================

.. include:: /installation/k8s-install-download-release.rst

Deploy Cilium release via Helm:

.. parsed-literal::

    helm install cilium |CHART_RELEASE|        \\
      --namespace kube-system                  \\
      --set hostFirewall.enabled=true          \\
      --set devices='{ethX,ethY}'

The ``devices`` flag refers to the network devices Cilium is configured on,
such as ``eth0``. If you omit this option, Cilium auto-detects what interfaces
the host firewall applies to. The resulting interfaces are shown in the
output of the ``cilium-dbg status`` command:

.. code-block:: shell-session

    $ kubectl exec -n kube-system ds/cilium -- \
         cilium-dbg status | grep 'Host firewall'

At this point, the Cilium-managed nodes are ready to enforce network policies.

Attach a Label to the Node
==========================

In this guide, host policies only apply to nodes with the label
``node-access=ssh``. Therefore, you first need to attach this label to a node
in the cluster:

.. code-block:: shell-session

    $ export NODE_NAME=k8s1
    $ kubectl label node $NODE_NAME node-access=ssh
    node/k8s1 labeled

Enable Policy Audit Mode for the Host Endpoint
==============================================

`HostPolicies` enforce access control over connectivity to and from nodes.
Particular care must be taken to ensure that when host policies are imported,
Cilium does not block access to the nodes or break the cluster's normal
behavior (for example by blocking communication with ``kube-apiserver``).

To avoid such issues, switch the host firewall in audit mode and validate the
impact of host policies before enforcing them.

.. warning::

   When Policy Audit Mode is enabled, no network policy is enforced so this
   setting is not recommended for production deployment.

Enable and check status for the Policy Audit Mode on the host endpoint for a
given node with the following commands:

.. code-block:: shell-session

    $ CILIUM_NAMESPACE=kube-system
    $ CILIUM_POD_NAME=$(kubectl -n $CILIUM_NAMESPACE get pods -l "k8s-app=cilium" -o jsonpath="{.items[?(@.spec.nodeName=='$NODE_NAME')].metadata.name}")
    $ alias kexec="kubectl -n $CILIUM_NAMESPACE exec $CILIUM_POD_NAME --"
    $ HOST_EP_ID=$(kexec cilium-dbg endpoint list -o jsonpath='{[?(@.status.identity.id==1)].id}')
    $ kexec cilium-dbg status | grep 'Host firewall'
    Host firewall:           Enabled   [eth0]
    $ kexec cilium-dbg endpoint config $HOST_EP_ID PolicyAuditMode=Enabled
    Endpoint 3353 configuration updated successfully
    $ kexec cilium-dbg endpoint config $HOST_EP_ID | grep PolicyAuditMode
    PolicyAuditMode        : Enabled

Apply a Host Network Policy
===========================

:ref:`HostPolicies` match on node labels using a :ref:`NodeSelector` to
identify the nodes to which the policies applies. They apply only to the host
namespace, including host-networking pods. They don't apply to communications
between pods or between pods and the outside of the cluster, except if those
pods are host-networking pods.

The following policy applies to all nodes with the ``node-access=ssh`` label.
It allows communications from outside the cluster only for TCP/22 and for ICMP
(ping) echo requests. All communications from the cluster to the hosts are
allowed.

.. literalinclude:: ../../examples/policies/host/demo-host-policy.yaml

To apply this policy, run:

.. parsed-literal::

    $ kubectl create -f \ |SCM_WEB|\/examples/policies/host/demo-host-policy.yaml
    ciliumclusterwidenetworkpolicy.cilium.io/demo-host-policy created

The host is represented as a special endpoint, with label ``reserved:host``, in
the output of command ``cilium-dbg endpoint list``. Use this command to inspect
the status of host policies:

.. code-block:: shell-session

    $ kexec cilium-dbg endpoint list
    ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])                       IPv6                 IPv4           STATUS
               ENFORCEMENT        ENFORCEMENT
    266        Disabled           Disabled          104        k8s:io.cilium.k8s.policy.cluster=default          f00d::a0b:0:0:ef4e   10.16.172.63   ready
                                                               k8s:io.cilium.k8s.policy.serviceaccount=coredns
                                                               k8s:io.kubernetes.pod.namespace=kube-system
                                                               k8s:k8s-app=kube-dns
    1687       Disabled (Audit)   Disabled          1          k8s:node-access=ssh                                                                   ready
                                                               reserved:host
    3362       Disabled           Disabled          4          reserved:health                                   f00d::a0b:0:0:49cf   10.16.87.66    ready

In this example, one can observe that policy enforcement on the host endpoint
is in audit mode for ingress traffic, and disabled for egress traffic.

Adjust the Host Policy to Your Environment
==========================================

As long as the host endpoint runs in audit mode, communications disallowed by
the policy are not dropped. Nevertheless, they are reported by ``cilium-dbg
monitor``, as ``action audit``. With these reports, the audit mode allows you
to adjust the host policy to your environment in order to avoid unexpected
connection breakages.

.. code-block:: shell-session

    $ kexec cilium-dbg monitor -t policy-verdict --related-to $HOST_EP_ID
    Policy verdict log: flow 0x0 local EP ID 1687, remote ID 6, proto 1, ingress, action allow, match L3-Only, 192.168.60.12 -> 192.168.60.11 EchoRequest
    Policy verdict log: flow 0x0 local EP ID 1687, remote ID 6, proto 6, ingress, action allow, match L3-Only, 192.168.60.12:37278 -> 192.168.60.11:2379 tcp SYN
    Policy verdict log: flow 0x0 local EP ID 1687, remote ID 2, proto 6, ingress, action audit, match none, 10.0.2.2:47500 -> 10.0.2.15:6443 tcp SYN

For details on deriving the network policies from the output of ``cilium
monitor``, refer to `observe_policy_verdicts` and `create_network_policy` in
the `policy_verdicts` guide.

Note that `Entities based` rules are convenient when combined with host
policies, for example to allow communication to entire classes of destinations,
such as all remotes nodes (``remote-node``) or the entire cluster
(``cluster``).

.. warning::

    Make sure that none of the communications required to access the cluster or
    for the cluster to work properly are denied. Ensure they all appear as
    ``action allow`` before disabling the audit mode.

.. _disable_policy_audit_mode:

Disable Policy Audit Mode
=========================

Once you are confident all required communications to the host from outside the
cluster are allowed, disable the policy audit mode to enforce the host policy:

.. code-block:: shell-session

    $ kexec cilium-dbg endpoint config $HOST_EP_ID PolicyAuditMode=Disabled
    Endpoint 3353 configuration updated successfully

Ingress host policies should now appear as enforced:

.. code-block:: shell-session

    $ kexec cilium-dbg endpoint list
    ENDPOINT   POLICY (ingress)   POLICY (egress)   IDENTITY   LABELS (source:key[=value])                       IPv6                 IPv4           STATUS
               ENFORCEMENT        ENFORCEMENT
    266        Disabled           Disabled          104        k8s:io.cilium.k8s.policy.cluster=default          f00d::a0b:0:0:ef4e   10.16.172.63   ready
                                                               k8s:io.cilium.k8s.policy.serviceaccount=coredns
                                                               k8s:io.kubernetes.pod.namespace=kube-system
                                                               k8s:k8s-app=kube-dns
    1687       Enabled            Disabled          1          k8s:node-access=ssh                                                                   ready
                                                               reserved:host
    3362       Disabled           Disabled          4          reserved:health                                   f00d::a0b:0:0:49cf   10.16.87.66    ready

Communications that are not explicitly allowed by the host policy are now
dropped:

.. code-block:: shell-session

    $ kexec cilium-dbg monitor -t policy-verdict --related-to $HOST_EP_ID
    Policy verdict log: flow 0x0 local EP ID 1687, remote ID 2, proto 6, ingress, action deny, match none, 10.0.2.2:49038 -> 10.0.2.15:21 tcp SYN

Clean up
========

.. code-block:: shell-session

   $ kubectl delete ccnp demo-host-policy
   $ kubectl label node $NODE_NAME node-access-

Further Reading
===============

Read the documentation on :ref:`HostPolicies` for additional details on how to
use the policies. In particular, refer to the :ref:`Troubleshooting Host
Policies <troubleshooting_host_policies>` subsection to understand how to debug
issues with Host Policies, or to the section on :ref:`Host Policies known
issues <host_policies_known_issues>` to understand the current limitations of
the feature.

only   not  epub or latex or html       WARNING  You are looking at unreleased Cilium documentation      Please use the official rendered version released here      https   docs cilium io      host firewall                 Host Firewall                This document serves as an introduction to Cilium s host firewall  to enforce security policies for Kubernetes nodes      admonition   Video    class  attention    You can also watch a video of Cilium s host firewall in action on    eCHO Episode 40  Cilium Host Firewall  https   www youtube com watch v GLLLcz398K0 t 288s       Enable the Host Firewall in Cilium                                        include    installation k8s install download release rst  Deploy Cilium release via Helm      parsed literal        helm install cilium  CHART RELEASE                    namespace kube system                             set hostFirewall enabled true                     set devices   ethX ethY    The   devices   flag refers to the network devices Cilium is configured on  such as   eth0    If you omit this option  Cilium auto detects what interfaces the host firewall applies to  The resulting interfaces are shown in the output of the   cilium dbg status   command      code block   shell session        kubectl exec  n kube system ds cilium               cilium dbg status   grep  Host firewall   At this point  the Cilium managed nodes are ready to enforce network policies    Attach a Label to the Node                             In this guide  host policies only apply to nodes with the label   node access ssh    Therefore  you first need to attach this label to a node in the cluster      code block   shell session        export NODE NAME k8s1       kubectl label node  NODE NAME node access ssh     node k8s1 labeled   Enable Policy Audit Mode for the Host Endpoint                                                  HostPolicies  enforce access control over connectivity to and from nodes  Particular care must be taken to ensure that when host policies are imported  Cilium does not block access to the nodes or break the cluster s normal behavior  for example by blocking communication with   kube apiserver      To avoid such issues  switch the host firewall in audit mode and validate the impact of host policies before enforcing them      warning       When Policy Audit Mode is enabled  no network policy is enforced so this    setting is not recommended for production deployment   Enable and check status for the Policy Audit Mode on the host endpoint for a given node with the following commands      code block   shell session        CILIUM NAMESPACE kube system       CILIUM POD NAME   kubectl  n  CILIUM NAMESPACE get pods  l  k8s app cilium   o jsonpath    items     spec nodeName    NODE NAME    metadata name          alias kexec  kubectl  n  CILIUM NAMESPACE exec  CILIUM POD NAME           HOST EP ID   kexec cilium dbg endpoint list  o jsonpath        status identity id  1   id          kexec cilium dbg status   grep  Host firewall      Host firewall            Enabled    eth0        kexec cilium dbg endpoint config  HOST EP ID PolicyAuditMode Enabled     Endpoint 3353 configuration updated successfully       kexec cilium dbg endpoint config  HOST EP ID   grep PolicyAuditMode     PolicyAuditMode          Enabled   Apply a Host Network Policy                               ref  HostPolicies  match on node labels using a  ref  NodeSelector  to identify the nodes to which the policies applies  They apply only to the host namespace  including host networking pods  They don t apply to communications between pods or between pods and the outside of the cluster  except if those pods are host networking pods   The following policy applies to all nodes with the   node access ssh   label  It allows communications from outside the cluster only for TCP 22 and for ICMP  ping  echo requests  All communications from the cluster to the hosts are allowed      literalinclude         examples policies host demo host policy yaml  To apply this policy  run      parsed literal          kubectl create  f    SCM WEB   examples policies host demo host policy yaml     ciliumclusterwidenetworkpolicy cilium io demo host policy created  The host is represented as a special endpoint  with label   reserved host    in the output of command   cilium dbg endpoint list    Use this command to inspect the status of host policies      code block   shell session        kexec cilium dbg endpoint list     ENDPOINT   POLICY  ingress    POLICY  egress    IDENTITY   LABELS  source key  value                         IPv6                 IPv4           STATUS                ENFORCEMENT        ENFORCEMENT     266        Disabled           Disabled          104        k8s io cilium k8s policy cluster default          f00d  a0b 0 0 ef4e   10 16 172 63   ready                                                                k8s io cilium k8s policy serviceaccount coredns                                                                k8s io kubernetes pod namespace kube system                                                                k8s k8s app kube dns     1687       Disabled  Audit    Disabled          1          k8s node access ssh                                                                   ready                                                                reserved host     3362       Disabled           Disabled          4          reserved health                                   f00d  a0b 0 0 49cf   10 16 87 66    ready  In this example  one can observe that policy enforcement on the host endpoint is in audit mode for ingress traffic  and disabled for egress traffic    Adjust the Host Policy to Your Environment                                             As long as the host endpoint runs in audit mode  communications disallowed by the policy are not dropped  Nevertheless  they are reported by   cilium dbg monitor    as   action audit    With these reports  the audit mode allows you to adjust the host policy to your environment in order to avoid unexpected connection breakages      code block   shell session        kexec cilium dbg monitor  t policy verdict   related to  HOST EP ID     Policy verdict log  flow 0x0 local EP ID 1687  remote ID 6  proto 1  ingress  action allow  match L3 Only  192 168 60 12    192 168 60 11 EchoRequest     Policy verdict log  flow 0x0 local EP ID 1687  remote ID 6  proto 6  ingress  action allow  match L3 Only  192 168 60 12 37278    192 168 60 11 2379 tcp SYN     Policy verdict log  flow 0x0 local EP ID 1687  remote ID 2  proto 6  ingress  action audit  match none  10 0 2 2 47500    10 0 2 15 6443 tcp SYN  For details on deriving the network policies from the output of   cilium monitor    refer to  observe policy verdicts  and  create network policy  in the  policy verdicts  guide   Note that  Entities based  rules are convenient when combined with host policies  for example to allow communication to entire classes of destinations  such as all remotes nodes    remote node    or the entire cluster    cluster         warning        Make sure that none of the communications required to access the cluster or     for the cluster to work properly are denied  Ensure they all appear as       action allow   before disabling the audit mode       disable policy audit mode   Disable Policy Audit Mode                            Once you are confident all required communications to the host from outside the cluster are allowed  disable the policy audit mode to enforce the host policy      code block   shell session        kexec cilium dbg endpoint config  HOST EP ID PolicyAuditMode Disabled     Endpoint 3353 configuration updated successfully  Ingress host policies should now appear as enforced      code block   shell session        kexec cilium dbg endpoint list     ENDPOINT   POLICY  ingress    POLICY  egress    IDENTITY   LABELS  source key  value                         IPv6                 IPv4           STATUS                ENFORCEMENT        ENFORCEMENT     266        Disabled           Disabled          104        k8s io cilium k8s policy cluster default          f00d  a0b 0 0 ef4e   10 16 172 63   ready                                                                k8s io cilium k8s policy serviceaccount coredns                                                                k8s io kubernetes pod namespace kube system                                                                k8s k8s app kube dns     1687       Enabled            Disabled          1          k8s node access ssh                                                                   ready                                                                reserved host     3362       Disabled           Disabled          4          reserved health                                   f00d  a0b 0 0 49cf   10 16 87 66    ready   Communications that are not explicitly allowed by the host policy are now dropped      code block   shell session        kexec cilium dbg monitor  t policy verdict   related to  HOST EP ID     Policy verdict log  flow 0x0 local EP ID 1687  remote ID 2  proto 6  ingress  action deny  match none  10 0 2 2 49038    10 0 2 15 21 tcp SYN   Clean up              code block   shell session       kubectl delete ccnp demo host policy      kubectl label node  NODE NAME node access   Further Reading                  Read the documentation on  ref  HostPolicies  for additional details on how to use the policies  In particular  refer to the  ref  Troubleshooting Host Policies  troubleshooting host policies   subsection to understand how to debug issues with Host Policies  or to the section on  ref  Host Policies known issues  host policies known issues   to understand the current limitations of the feature


cilium Cilium environment running on your machine It is designed to take 15 30 docs cilium io security policies It is a detailed walk through of getting a single node This document serves as an introduction for using Cilium to enforce Elasticsearch aware minutes Securing Elasticsearch

Answer:
.. only:: not (epub or latex or html)

    WARNING: You are looking at unreleased Cilium documentation.
    Please use the official rendered version released here:
    https://docs.cilium.io

**********************
Securing Elasticsearch
**********************

This document serves as an introduction for using Cilium to enforce Elasticsearch-aware
security policies.  It is a detailed walk-through of getting a single-node
Cilium environment running on your machine. It is designed to take 15-30
minutes.

.. include:: gsg_requirements.rst

Deploy the Demo Application
===========================

Following the Cilium tradition, we will use a Star Wars-inspired example. The Empire has a large scale Elasticsearch cluster which is used for storing a variety of data including:

* ``index: troop_logs``: Stormtroopers performance logs collected from every outpost which are used to identify and eliminate weak performers!
* ``index: spaceship_diagnostics``: Spaceships diagnostics data collected from every spaceship which is used for R&D and improvement of the spaceships.

Every outpost has an Elasticsearch client service to upload the Stormtroopers logs. And every spaceship has a service to upload diagnostics. Similarly, the Empire headquarters has a service to search and analyze the troop logs and spaceship diagnostics data. Before we look into the security concerns, let's first create this application scenario in minikube.

Deploy the app using command below, which will create

* An ``elasticsearch`` service with the selector label ``component:elasticsearch`` and a pod running Elasticsearch.
* Three Elasticsearch clients one each for ``empire-hq``, ``outpost`` and ``spaceship``.

.. parsed-literal::

    $ kubectl create -f \ |SCM_WEB|\/examples/kubernetes-es/es-sw-app.yaml
    serviceaccount "elasticsearch" created
    service "elasticsearch" created
    replicationcontroller "es" created
    role "elasticsearch" created
    rolebinding "elasticsearch" created
    pod "outpost" created
    pod "empire-hq" created
    pod "spaceship" created

.. code-block:: shell-session

    $ kubectl get svc,pods
    NAME                TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)                           AGE
    svc/elasticsearch   NodePort    10.111.238.254   <none>        9200:30130/TCP,9300:31721/TCP     2d
    svc/etcd-cilium     NodePort    10.98.67.60      <none>        32379:31079/TCP,32380:31080/TCP   9d
    svc/kubernetes      ClusterIP   10.96.0.1        <none>        443/TCP                           9d

    NAME               READY     STATUS    RESTARTS   AGE
    po/empire-hq       1/1       Running   0          2d
    po/es-g9qk2        1/1       Running   0          2d
    po/etcd-cilium-0   1/1       Running   0          9d
    po/outpost         1/1       Running   0          2d
    po/spaceship       1/1       Running   0          2d

Security Risks for Elasticsearch Access
=======================================

For Elasticsearch clusters the **least privilege security** challenge is to give clients access only to particular indices, and to limit the operations each client is allowed to perform on each index. In this example, the ``outpost`` Elasticsearch clients only need access to upload troop logs; and the ``empire-hq`` client only needs search access to both the indices.  From the security perspective, the outposts are weak spots and susceptible to be captured by the rebels. Once compromised, the clients can be used to search and manipulate the critical data in Elasticsearch. We can simulate this attack, but first let's run the commands for legitimate behavior for all the client services.

``outpost`` client uploading troop logs

.. code-block:: shell-session

    $ kubectl exec outpost -- python upload_logs.py
    Uploading Stormtroopers Performance Logs
    created :  {'_index': 'troop_logs', '_type': 'log', '_id': '1', '_version': 1, 'result': 'created', '_shards': {'total': 2, 'successful': 1, 'failed': 0}, 'created': True}

``spaceship`` uploading diagnostics

.. code-block:: shell-session

    $ kubectl exec spaceship -- python upload_diagnostics.py
    Uploading Spaceship Diagnostics
    created :  {'_index': 'spaceship_diagnostics', '_type': 'stats', '_id': '1', '_version': 1, 'result': 'created', '_shards': {'total': 2, 'successful': 1, 'failed': 0}, 'created': True}

``empire-hq`` running search queries for logs and diagnostics

.. code-block:: shell-session

    $ kubectl exec empire-hq -- python search.py
    Searching for Spaceship Diagnostics
    Got 1 Hits:
    {'_index': 'spaceship_diagnostics', '_type': 'stats', '_id': '1', '_score': 1.0, \
     '_source': {'spaceshipid': '3459B78XNZTF', 'type': 'tiefighter', 'title': 'Engine Diagnostics', \
                 'stats': '[CRITICAL] [ENGINE BURN @SPEED 5000 km/s] [CHANCE 80%]'}}
    Searching for Stormtroopers Performance Logs
    Got 1 Hits:
    {'_index': 'troop_logs', '_type': 'log', '_id': '1', '_score': 1.0, \
     '_source': {'outpost': 'Endor', 'datetime': '33 ABY 4AM DST', 'title': 'Endor Corps 1: Morning Drill', \
                 'notes': '5100 PRESENT; 15 ABSENT; 130 CODE-RED BELOW PAR PERFORMANCE'}}

Now imagine an outpost captured by the rebels. In the commands below, the rebels first search all the indices and then manipulate the diagnostics data from a compromised outpost.

.. code-block:: shell-session

    $ kubectl exec outpost -- python search.py
    Searching for Spaceship Diagnostics
    Got 1 Hits:
    {'_index': 'spaceship_diagnostics', '_type': 'stats', '_id': '1', '_score': 1.0, \
     '_source': {'spaceshipid': '3459B78XNZTF', 'type': 'tiefighter', 'title': 'Engine Diagnostics', \
                 'stats': '[CRITICAL] [ENGINE BURN @SPEED 5000 km/s] [CHANCE 80%]'}}
    Searching for Stormtroopers Performance Logs
    Got 1 Hits:
    {'_index': 'troop_logs', '_type': 'log', '_id': '1', '_score': 1.0, \
     '_source': {'outpost': 'Endor', 'datetime': '33 ABY 4AM DST', 'title': 'Endor Corps 1: Morning Drill', \
                 'notes': '5100 PRESENT; 15 ABSENT; 130 CODE-RED BELOW PAR PERFORMANCE'}}

Rebels manipulate spaceship diagnostics data so that the spaceship defects are not known to the empire-hq! (Hint: Rebels have changed the ``stats`` for the tiefighter spaceship, a change hard to detect but with adverse impact!)

.. code-block:: shell-session

    $ kubectl exec outpost -- python update.py
    Uploading Spaceship Diagnostics
    {'_index': 'spaceship_diagnostics', '_type': 'stats', '_id': '1', '_score': 1.0, \
     '_source': {'spaceshipid': '3459B78XNZTF', 'type': 'tiefighter', 'title': 'Engine Diagnostics', \
                 'stats': '[OK] [ENGINE OK @SPEED 5000 km/s]'}}

Securing Elasticsearch Using Cilium
====================================

.. image:: images/cilium_es_gsg_topology.png
   :scale: 40 %

Following the least privilege security principle, we want to the allow the following legitimate actions and nothing more:

* ``outpost`` service only has upload access to ``index: troop_logs``
* ``spaceship`` service only has upload access to ``index: spaceship_diagnostics``
* ``empire-hq`` service only has search access for both the indices

Fortunately, the Empire DevOps team is using Cilium for their Kubernetes cluster. Cilium provides L7 visibility and security policies to control Elasticsearch API access. Cilium follows the **white-list, least privilege model** for security. That is to say, a *CiliumNetworkPolicy* contains a list of rules that define **allowed requests** and any request that does not match the rules is denied.

In this example, the policy rules are defined for inbound traffic (i.e., "ingress") connections to the *elasticsearch* service. Note that endpoints selected as backend pods for the service are defined by the *selector* labels. *Selector* labels use the same concept as Kubernetes to define a service. In this example, label ``component: elasticsearch`` defines the pods that are part of the *elasticsearch* service in Kubernetes.

In the policy file below, you will see the following rules for controlling the indices access and actions performed:

* ``fromEndpoints`` with labels ``app:spaceship`` only ``HTTP`` ``PUT`` is allowed on paths matching regex ``^/spaceship_diagnostics/stats/.*$``
* ``fromEndpoints`` with labels ``app:outpost`` only ``HTTP`` ``PUT`` is allowed on paths matching regex ``^/troop_logs/log/.*$``
* ``fromEndpoints`` with labels ``app:empire`` only ``HTTP`` ``GET`` is allowed on paths matching regex ``^/spaceship_diagnostics/_search/??.*$`` and ``^/troop_logs/search/??.*$``

.. literalinclude:: ../../examples/kubernetes-es/es-sw-policy.yaml

Apply this Elasticsearch-aware network security policy using ``kubectl``:

.. parsed-literal::

    $ kubectl create -f \ |SCM_WEB|\/examples/kubernetes-es/es-sw-policy.yaml
    ciliumnetworkpolicy "secure-empire-elasticsearch" created

Let's test the security policies. Firstly, the search access is blocked for both outpost and spaceship. So from a compromised outpost, rebels will not be able to search and obtain knowledge about troops and spaceship diagnostics. Secondly, the outpost clients don't have access to create or update the ``index: spaceship_diagnostics``.

.. code-block:: shell-session

    $ kubectl exec outpost -- python search.py
    GET http://elasticsearch:9200/spaceship_diagnostics/_search [status:403 request:0.008s]
    ...
    ...
    elasticsearch.exceptions.AuthorizationException: TransportError(403, 'Access denied\r\n')
    command terminated with exit code 1

.. code-block:: shell-session

    $ kubectl exec outpost -- python update.py
    PUT http://elasticsearch:9200/spaceship_diagnostics/stats/1 [status:403 request:0.006s]
    ...
    ...
    elasticsearch.exceptions.AuthorizationException: TransportError(403, 'Access denied\r\n')
    command terminated with exit code 1

We can re-run any of the below commands to show that the security policy still allows all legitimate requests (i.e., no 403 errors are returned).

.. code-block:: shell-session

    $ kubectl exec outpost -- python upload_logs.py
    ...
    $ kubectl exec spaceship -- python upload_diagnostics.py
    ...
    $ kubectl exec empire-hq -- python search.py
    ...

Clean Up
========

You have now installed Cilium, deployed a demo app, and finally deployed & tested Elasticsearch-aware network security policies. To clean up, run:

.. parsed-literal::

   $ kubectl delete -f \ |SCM_WEB|\/examples/kubernetes-es/es-sw-app.yaml
   $ kubectl delete cnp secure-empire-elasticsearch

only   not  epub or latex or html       WARNING  You are looking at unreleased Cilium documentation      Please use the official rendered version released here      https   docs cilium io                         Securing Elasticsearch                         This document serves as an introduction for using Cilium to enforce Elasticsearch aware security policies   It is a detailed walk through of getting a single node Cilium environment running on your machine  It is designed to take 15 30 minutes      include   gsg requirements rst  Deploy the Demo Application                              Following the Cilium tradition  we will use a Star Wars inspired example  The Empire has a large scale Elasticsearch cluster which is used for storing a variety of data including        index  troop logs    Stormtroopers performance logs collected from every outpost which are used to identify and eliminate weak performers      index  spaceship diagnostics    Spaceships diagnostics data collected from every spaceship which is used for R D and improvement of the spaceships   Every outpost has an Elasticsearch client service to upload the Stormtroopers logs  And every spaceship has a service to upload diagnostics  Similarly  the Empire headquarters has a service to search and analyze the troop logs and spaceship diagnostics data  Before we look into the security concerns  let s first create this application scenario in minikube   Deploy the app using command below  which will create    An   elasticsearch   service with the selector label   component elasticsearch   and a pod running Elasticsearch    Three Elasticsearch clients one each for   empire hq      outpost   and   spaceship         parsed literal          kubectl create  f    SCM WEB   examples kubernetes es es sw app yaml     serviceaccount  elasticsearch  created     service  elasticsearch  created     replicationcontroller  es  created     role  elasticsearch  created     rolebinding  elasticsearch  created     pod  outpost  created     pod  empire hq  created     pod  spaceship  created     code block   shell session        kubectl get svc pods     NAME                TYPE        CLUSTER IP       EXTERNAL IP   PORT S                            AGE     svc elasticsearch   NodePort    10 111 238 254    none         9200 30130 TCP 9300 31721 TCP     2d     svc etcd cilium     NodePort    10 98 67 60       none         32379 31079 TCP 32380 31080 TCP   9d     svc kubernetes      ClusterIP   10 96 0 1         none         443 TCP                           9d      NAME               READY     STATUS    RESTARTS   AGE     po empire hq       1 1       Running   0          2d     po es g9qk2        1 1       Running   0          2d     po etcd cilium 0   1 1       Running   0          9d     po outpost         1 1       Running   0          2d     po spaceship       1 1       Running   0          2d   Security Risks for Elasticsearch Access                                          For Elasticsearch clusters the   least privilege security   challenge is to give clients access only to particular indices  and to limit the operations each client is allowed to perform on each index  In this example  the   outpost   Elasticsearch clients only need access to upload troop logs  and the   empire hq   client only needs search access to both the indices   From the security perspective  the outposts are weak spots and susceptible to be captured by the rebels  Once compromised  the clients can be used to search and manipulate the critical data in Elasticsearch  We can simulate this attack  but first let s run the commands for legitimate behavior for all the client services      outpost   client uploading troop logs      code block   shell session        kubectl exec outpost    python upload logs py      Uploading Stormtroopers Performance Logs     created       index    troop logs     type    log     id    1     version   1   result    created     shards     total   2   successful   1   failed   0    created   True     spaceship   uploading diagnostics     code block   shell session        kubectl exec spaceship    python upload diagnostics py      Uploading Spaceship Diagnostics     created       index    spaceship diagnostics     type    stats     id    1     version   1   result    created     shards     total   2   successful   1   failed   0    created   True     empire hq   running search queries for logs and diagnostics     code block   shell session        kubectl exec empire hq    python search py      Searching for Spaceship Diagnostics     Got 1 Hits         index    spaceship diagnostics     type    stats     id    1     score   1 0           source     spaceshipid    3459B78XNZTF    type    tiefighter    title    Engine Diagnostics                       stats     CRITICAL   ENGINE BURN  SPEED 5000 km s   CHANCE 80          Searching for Stormtroopers Performance Logs     Got 1 Hits         index    troop logs     type    log     id    1     score   1 0           source     outpost    Endor    datetime    33 ABY 4AM DST    title    Endor Corps 1  Morning Drill                       notes    5100 PRESENT  15 ABSENT  130 CODE RED BELOW PAR PERFORMANCE      Now imagine an outpost captured by the rebels  In the commands below  the rebels first search all the indices and then manipulate the diagnostics data from a compromised outpost       code block   shell session        kubectl exec outpost    python search py      Searching for Spaceship Diagnostics     Got 1 Hits         index    spaceship diagnostics     type    stats     id    1     score   1 0           source     spaceshipid    3459B78XNZTF    type    tiefighter    title    Engine Diagnostics                       stats     CRITICAL   ENGINE BURN  SPEED 5000 km s   CHANCE 80          Searching for Stormtroopers Performance Logs     Got 1 Hits         index    troop logs     type    log     id    1     score   1 0           source     outpost    Endor    datetime    33 ABY 4AM DST    title    Endor Corps 1  Morning Drill                       notes    5100 PRESENT  15 ABSENT  130 CODE RED BELOW PAR PERFORMANCE     Rebels manipulate spaceship diagnostics data so that the spaceship defects are not known to the empire hq   Hint  Rebels have changed the   stats   for the tiefighter spaceship  a change hard to detect but with adverse impact        code block   shell session        kubectl exec outpost    python update py      Uploading Spaceship Diagnostics        index    spaceship diagnostics     type    stats     id    1     score   1 0           source     spaceshipid    3459B78XNZTF    type    tiefighter    title    Engine Diagnostics                       stats     OK   ENGINE OK  SPEED 5000 km s       Securing Elasticsearch Using Cilium                                           image   images cilium es gsg topology png     scale  40    Following the least privilege security principle  we want to the allow the following legitimate actions and nothing more       outpost   service only has upload access to   index  troop logs       spaceship   service only has upload access to   index  spaceship diagnostics       empire hq   service only has search access for both the indices   Fortunately  the Empire DevOps team is using Cilium for their Kubernetes cluster  Cilium provides L7 visibility and security policies to control Elasticsearch API access  Cilium follows the   white list  least privilege model   for security  That is to say  a  CiliumNetworkPolicy  contains a list of rules that define   allowed requests   and any request that does not match the rules is denied    In this example  the policy rules are defined for inbound traffic  i e    ingress   connections to the  elasticsearch  service  Note that endpoints selected as backend pods for the service are defined by the  selector  labels   Selector  labels use the same concept as Kubernetes to define a service  In this example  label   component  elasticsearch   defines the pods that are part of the  elasticsearch  service in Kubernetes   In the policy file below  you will see the following rules for controlling the indices access and actions performed       fromEndpoints   with labels   app spaceship   only   HTTP     PUT   is allowed on paths matching regex     spaceship diagnostics stats           fromEndpoints   with labels   app outpost   only   HTTP     PUT   is allowed on paths matching regex     troop logs log           fromEndpoints   with labels   app empire   only   HTTP     GET   is allowed on paths matching regex     spaceship diagnostics  search         and     troop logs search             literalinclude         examples kubernetes es es sw policy yaml  Apply this Elasticsearch aware network security policy using   kubectl        parsed literal          kubectl create  f    SCM WEB   examples kubernetes es es sw policy yaml     ciliumnetworkpolicy  secure empire elasticsearch  created  Let s test the security policies  Firstly  the search access is blocked for both outpost and spaceship  So from a compromised outpost  rebels will not be able to search and obtain knowledge about troops and spaceship diagnostics  Secondly  the outpost clients don t have access to create or update the   index  spaceship diagnostics         code block   shell session        kubectl exec outpost    python search py      GET http   elasticsearch 9200 spaceship diagnostics  search  status 403 request 0 008s                      elasticsearch exceptions AuthorizationException  TransportError 403   Access denied r n       command terminated with exit code 1     code block   shell session        kubectl exec outpost    python update py      PUT http   elasticsearch 9200 spaceship diagnostics stats 1  status 403 request 0 006s                      elasticsearch exceptions AuthorizationException  TransportError 403   Access denied r n       command terminated with exit code 1  We can re run any of the below commands to show that the security policy still allows all legitimate requests  i e   no 403 errors are returned       code block   shell session        kubectl exec outpost    python upload logs py                kubectl exec spaceship    python upload diagnostics py                kubectl exec empire hq    python search py            Clean Up           You have now installed Cilium  deployed a demo app  and finally deployed   tested Elasticsearch aware network security policies  To clean up  run      parsed literal         kubectl delete  f    SCM WEB   examples kubernetes es es sw app yaml      kubectl delete cnp secure empire elasticsearch