Merge "Document briefly how services in k8s work and why 0.0.0.0 is OK."
This commit is contained in:
commit
bfd322fead
|
@ -0,0 +1,71 @@
|
|||
=========================================================================
|
||||
Kubernetes Service Security... or, "Why is everything binding to 0.0.0.0"
|
||||
=========================================================================
|
||||
|
||||
Traditional OpenStack installs have generally used split networks (either VLAN
|
||||
segments or multi-port NICs and independent networks). Kubernetes is designed
|
||||
with the assumption that users are going to have a SDN fabric installed, of
|
||||
which there are several different options using the CNI (Container Networking
|
||||
Interface) API. Both underlay and overlay networking options are available as
|
||||
CNI services.
|
||||
|
||||
The Kubernetes fabric is mediated by the ``kube-proxy`` executable, thus even
|
||||
software running on the node outside of a container is able to see Kubernetes
|
||||
services.
|
||||
|
||||
How are ports exposed?
|
||||
======================
|
||||
|
||||
While using ``HostNetwork=True`` (``Net=Host`` in Docker parlance), processes
|
||||
running inside of a container are using the network namespace of the host,
|
||||
meaning that network operations are not containerized and, as far as the TCP/IP
|
||||
stack is concerned, the process is running in the parent host. This means
|
||||
that any process need to be just as careful about what ports are accessible
|
||||
and how they are managing them as a process running outside of the container.
|
||||
Thus, they must be careful which interface they listen to, who is allowed to
|
||||
connect, etc.
|
||||
|
||||
In Kubernetes, containers default to ``HostNetwork=False`` and thus work
|
||||
inside of the Kubernetes network framework. They have no inbound ports
|
||||
accessible by default unless you have set them to be exposed.
|
||||
|
||||
The normal way of exposing ports is via a Kubernetes Service. A service has a
|
||||
DNS alias exposed via SkyDNS (e.g. you are able to use ``mariadb`` to access
|
||||
MariaDB) that points to the service IP address which is generally backed by a
|
||||
Kubernetes Virtual IP. Services can be either internal services or external
|
||||
services. Only services specifically marked as external services and
|
||||
configured with either a LoadBalancer or a Ingress controller will be
|
||||
accessible outside of the cluster.
|
||||
|
||||
Services can be exposed with a type of ``NodePort``, which means that a port
|
||||
from a configurable range will be allocated for a service on each node on each
|
||||
port will be configured to proxy, which is intended for users to be able to
|
||||
configure their own external load balancers.
|
||||
|
||||
Thus, a server running inside of a container that doesn't have any services
|
||||
exposed as ``NodePort`` can safely bind to 0.0.0.0 and rely on the underlying
|
||||
network layer ensuring that attackers are unable to probe for it.
|
||||
|
||||
Containers that need to run as ``HostNetwork=True`` are unable to be exposed
|
||||
as services but are still able to connect to other Kubernetes services.
|
||||
|
||||
What about other services running inside of the Kubernetes cluster?
|
||||
===================================================================
|
||||
|
||||
By default, processes running on compute nodes within the cluster are part of
|
||||
the same unrestricted network fabric.
|
||||
|
||||
Certain processes, Nova Compute nodes, for example, are running user workloads
|
||||
out of the control of the cluster administrator and thus should not have
|
||||
unrestricted access to the cluster. There are two alternatives:
|
||||
|
||||
First, compute nodes can be provisioned outside of the Kubernetes cluster.
|
||||
This is necessary if you are using compute nodes with KVM or Ironic and often
|
||||
times the easiest approach.
|
||||
|
||||
Second, some of the CNI drivers (Calico being one example) can be configured
|
||||
with NetworkPolicy objects to block access from certain nodes, which can
|
||||
prevent compute nodes from seeing the internal services. However, as
|
||||
currently implemented, pods will still be accessible from the host on which
|
||||
they are running, it is also necessary to schedule any containers with
|
||||
``HostNetworking=True`` on dedicated hosts.
|
Loading…
Reference in New Issue