The Gardener project team has analyzed the impact of the Gardener CVE-2018-2475 and the Kubernetes CVE-2018-1002105 on the Gardener Community Setup. Following some recommendations it is possible to mitigate both vulnerabilities. Read more on Hardening the Gardener Community Setup.
In summer 2018, the Gardener project team asked Kinvolk to execute several penetration tests in its role as third-party contractor. The goal of this ongoing work is to increase the security of all Gardener stakeholders in the open source community. Following the Gardener architecture, the control plane of a Gardener managed shoot cluster resides in the corresponding seed cluster. This is a Control-Plane-as-a-Service with a network air gap.
Along the way we found various kinds of security issues, for example, due to misconfiguration or missing isolation, as well as two special problems with upstream Kubernetes and its Control-Plane-as-a-Service architecture.
..read some more on Auditing Kubernetes for Secure Setup.
You want to experiment with Kubernetes or have set up a customer scenario, but you don’t want to run the cluster 24 / 7 for reasons of cost?
The Gardener gives you the possibility to scale your cluster down to zero nodes.
..read some more on Hibernate a Cluster.
The efs-provisioner allows you to mount EFS storage as PersistentVolumes in kubernetes. It consists of a container that has access to an AWS EFS resource. The container reads a configmap containing the EFS filesystem ID, the AWS region and the name identifying the efs-provisioner. This name will be used later when you create a storage class.
..read some more on ReadWriteMany.
Whenever possible, do not run containers as root users. One could be
tempted to say that Kubernetes Pods and Node are well separated. The host and the container
share the same kernel. If the container is compromised, a root user can damage the underlying
node. Use RUN groupadd -r anygroup && useradd -r -g anygroup myuser to create a group
and a user in it. Use the USER command to switch to this user.
Containers are ideal for stateless applications and should be transient. This means that no data or logs should be stored in the container, as they are lost when the container is closed. If absolutely necessary, you can use persistence volumes instead to persist them outside the containers. However, an ELK stack is preferred for storing and processing log files.
..read some more on Common Kubernetes Antipattern.
For encrypted communication between the client to the load balancer, you need to specify a TLS private key and certificate to be used by the ingress controller.
Create a secret in the namespace of the ingress containing the TLS private key and certificate. Then configure the secret name in the TLS configuration section of the ingress specification.
..read on HTTPS - Self Signed Certificates how to configure it.
The storage is definitely the most complex and important part of an application setup, once this part is completed, one of the most problematic parts could be solved.
Mounting a S3 bucket into a pod using FUSE allows to access data stored in S3 via the filesystem. The mount is a pointer to an S3 location, so the data is never synced locally. Once mounted, any pod can read or even write from that directory without the need for explicit keys.
However, it can be used to import and parse large amounts of data into a database.
..read on Shared S3 Storage how to configure it.
…or DENY all traffic from other namespaces
You can configure a NetworkPolicy to deny all traffic from other namespaces while allowing all traffic coming from the same namespace the pod is deployed to. There are many reasons why you may chose to configure Kubernetes network policies: - Isolate multi-tenant deployments - Regulatory compliance - Ensure containers assigned to different environments (e.g. dev/staging/prod) cannot interfere with each another
..read on Namespace Isolation how to configure it.
Should I use:
Apply the Principle of Least Privilege
All user accounts should run at all times as few privileges as possible, and also
launch applications with as few privileges as possible. If you share a cluster for
different user separated by a namespace, all user has access to all namespaces and
services per default. It can happen that a user accidentally uses and destroys the
namespace of a productive application or the namespace of another developer.
Keep in mind: By default namespaces don’t provide: - Network isolation - Access Control - Audit Logging on user level
One thing that always bothered me was that I couldn’t get logs of several pods at once with kubectl. A simple
tail -f <path-to-logfile> isn’t possible. Certainly you can use kubectl logs -f <pod-id>, but it doesn’t
help if you want to monitor more than one pod at a time.
This is something you really need a lot, at least if you run several instances of a pod behind a deployment
and you don’t have setup a log viewer service like Kibana.
kubetail comes to the rescue, it is a small bash script that allows you to aggregate log files of several pods at
the same time in a simple way. The script is called kubetail and is available at
https://github.com/johanhaleby/kubetail.
Microservices tend to use smaller runtimes but you can use what you have today - and this can be a problem in kubernetes.
Switching your architecture from a monolith to microservices has many advantages, both in the way you write software and the way it is used throughout its lifecycle. In this post, my attempt is to cover one problem which does not get as much attention and discussion - size of the technology stack.
There is a tendency to be more generalized in development and to apply this pattern to all services. One feels that a homogeneous image of the technology stack is good if it is the same for all services.
One forgets, however, that a large percentage of the integrated infrastructure is not used by all services in the same way, and is therefore only a burden. Thus, resources are wasted and the entire application becomes expensive in operation and scales very badly.
Due to the lightweight nature of your service, you can run more containers on a physical server and virtual machines. The result is higher resource utilization.
Additionally, microservices are developed and deployed as containers independently of each another. This means that a development team can develop, optimize and deploy a microservice without impacting other subsystems.
|
Kubernetes is only available in Docker for Mac 17.12 CE and higher on the Edge channel. Kubernetes
support is not included in Docker for Mac Stable releases. To find out more about Stable and Edge channels
and how to switch between them, see
general configuration.
|
The Kubernetes client command, kubectl, is included and configured to connect to the local Kubernetes server. If you have kubectl already installed and pointing to some other environment, such as minikube or a GKE cluster, be sure to change context so that kubectl is pointing to docker-for-desktop:
…see more on Docker.com
I recommend to setup your shell to see which KUBECONFIG is active.
Report an issue
