Admission-Control

前一段时间将之前采用kubeadm安装的Kubernetes 1.5.1环境升级到了1.6.4版本，升级过程较为顺利。由于该k8s cluster是一个测试环境，当时并没有过于关注，就忙别的事情了。最近项目组打算在这个环境下做一些事情，而当我们重新“捡起”这个环境时，发现Kubernetes Dashboard无法访问了。 ...

Kubernetes API Server是整个Kubernetes集群的核心，我们不仅有从集群外部访问API Server的需求，有时，我们还需要从Pod的内部访问API Server。 然而，在生产环境中，Kubernetes API Server都是“设防”的。在《Kubernetes集群的安全配置》一文中，我提到过：Kubernetes通过client cert、static token、basic auth等方法对客户端请求进行身份验证。对于运行于Pod中的Process而言，有些时候这些方法是适合的，但有些时候，像client cert、static token或basic auth这些信息是不便于暴露给Pod中的Process的。并且通过这些方法通过API Server验证后的请求是具有全部授权的，可以任意操作Kubernetes cluster，这显然是不能满足安全要求的。为此，Kubernetes更推荐大家使用service account这种方案的。本文就带大家详细说说如何通过service account从一个Pod中访问API Server的。 ...

使用kubernetes/cluster/kube-up.sh脚本在装有Ubuntu操作系统的bare metal上搭建的Kubernetes集群并不安全，甚至可以说是“完全不设防的”，这是因为Kubernetes集群的核心组件：kube-apiserver启用了insecure-port。insecure-port背后的api server默认完全信任访问该端口的流量，内部无任何安全机制。并且监听insecure-port的api server bind的insecure-address为0.0.0.0。也就是说任何内外部请求，都可以通过insecure-port端口任意操作Kubernetes集群。我们的平台虽小，但“裸奔”的k8s集群也并不是我们想看到的，适当的安全配置是需要的。 ...