轻松了解Kubernetes认证功能
Kubernetes 简称k8s,是谷歌于2014年开始主导的开源项目,提供了以容器为中心的部署、伸缩和运维平台。截止目前它的最新版本为1.2。搭建环境之前建议先了解一下kubernetes的相关知识,可以参考 《如果有10000台机器,你想怎么玩?》 系列文章。本文介绍kubernetes的安全性配置。
准备工作
首先需要搭建kubernetes集群环境,可以参考 《轻松搭建Kubernetes 1.2版运行环境》 来安装自己的kubernetes集群,运行到flannel配置完成即可。接下来的api server等设置的参数可以参考本文。
结果应该是有三台虚拟机,一台叫做 master ,它的IP是 192.168.33.17 ,运行 着k8s的api server、controller manager和scheduler;另两台叫做 node1 和 node2 ,它们的IP分别是 192.168.33.18 和 192.168.33.19 ,运行着k8s的kubelet和kube-proxy,当做k8s的两个节点。
部署
最简单的方式就是通过基于CSV的基本认证。首先需要创建api server的基本认证文件:
master
cd ~ mkdir security echo 123456,admin,qinghua > security/basic_auth.csv # 格式:用户名,密码,用户ID
然后就可以生成CA和api server的证书了:
master
cd security openssl genrsa -out ca.key 2048 openssl req -x509 -new -nodes -key ca.key -subj "/CN=192.168.33.17" -days 10000 -out ca.crt openssl genrsa -out server.key 2048 openssl req -new -key server.key -subj "/CN=192.168.33.17" -out server.csr openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out server.crt -days 10000 cd ..
上面的命令会生成若干证书相关文件,作用如下:
- ca.key:自己生成的CA的私钥,用于模拟一个CA
- ca.crt:用自己的私钥自签名的CA证书
- server.key:api server的私钥,用于配置api server的https
- server.csr:api server的证书请求文件,用于请求api server的证书
- server.crt:用自己模拟的CA签发的api server的证书,用于配置api server的https
接下来启动api server,参数的作用可以参考 kube-apiserver官方文档 :
master
docker run -d \ --name=apiserver \ --net=host \ -v /home/vagrant/security:/security \ gcr.io/google_containers/kube-apiserver:e68c6af15d4672feef7022e94ee4d9af \ kube-apiserver \ --advertise-address=192.168.33.17 \ --admission-control=ServiceAccount \ --insecure-bind-address=0.0.0.0 \ --etcd-servers=http://192.168.33.17:4001 \ --service-cluster-ip-range=11.0.0.0/16 \ --tls-cert-file=/security/server.crt \ --tls-private-key-file=/security/server.key \ --secure-port=443 \ --basic-auth-file=/security/basic_auth.csv
还需要启动controller manager,参数的作用可以参考 kube-controller-manager官方文档 :
master
docker run -d \ --name=cm \ -v /home/vagrant/security:/security \ gcr.io/google_containers/kube-controller-manager:b9107c794e0564bf11719dc554213f7b \ kube-controller-manager \ --master=192.168.33.17:8080 \ --cluster-cidr=10.245.0.0/16 \ --allocate-node-cidrs=true \ --root-ca-file=/security/ca.crt \ --service-account-private-key-file=/security/server.key
最后是scheduler,参数的作用可以参考 kube-scheduler官方文档 :
master
docker run -d \ --name=scheduler \ gcr.io/google_containers/kube-scheduler:903b34d5ed7367ec4dddf846675613c9 \ kube-scheduler \ --master=192.168.33.17:8080
可以运行以下命令来确认安全配置已经生效:
master
curl -k -u admin:123456 https://127.0.0.1/ curl -k -u admin:123456 https://127.0.0.1/api/v1
最后启动kubelet和kube-proxy,参数的作用可以参考 kubelet官方文档 和 kube-proxy官方文档 :
node1 node2
NODE_IP=`ifconfig eth1 | grep 'inet addr:' | cut -d: -f2 | cut -d' ' -f1` sudo kubernetes/server/bin/kubelet \ --api-servers=192.168.33.17:8080 \ --cluster-dns=11.0.0.10 \ --cluster-domain=cluster.local \ --hostname-override=$NODE_IP \ --node-ip=$NODE_IP > kubelet.log 2>&1 & sudo kubernetes/server/bin/kube-proxy \ --master=192.168.33.17:8080 \ --hostname-override=$NODE_IP > proxy.log 2>&1 &
验证
如果需要通过https访问,kubectl的命令就略微有点儿麻烦了,需要用 basic_auth.csv
里配置的 admin/123456
来登录:
master
~/kubernetes/server/bin/kubectl -s https://192.168.33.17 --insecure-skip-tls-verify=true --username=admin --password=123456 get po
因为8080端口还开着,所以也可以通过http访问:
master
~/kubernetes/server/bin/kubectl -s http://192.168.33.17:8080 get po
配置完成后,可以看到系统里有TYPE为 kubernetes.io/service-account-token
的秘密:
master
~/kubernetes/server/bin/kubectl -s http://192.168.33.17:8080 get secret
里面有三条数据,分别是 ca.crt
, namespace
和 token
,可以通过以下命令看到:
master
~/kubernetes/server/bin/kubectl -s http://192.168.33.17:8080 describe secret
如果你通过kubernetes启动了一个pod,就可以在容器的 /var/run/secrets/kubernetes.io/serviceaccount/
目录里看到以三个文件的形式看到这三条数据(这是 --admission-control=ServiceAccount
的功劳),当pod需要访问系统服务的时候,就可以使用它们了。可以使用以下命令看到系统的服务账号:
master
~/kubernetes/server/bin/kubectl -s http://192.168.33.17:8080 get serviceAccount
简化kubectl
如果我们通过设置 --insecure-port=0
把api server的http端口关闭,那它就只能通过https访问了:
master
docker rm -f apiserver docker run -d \ --name=apiserver \ --net=host \ -v /home/vagrant/security:/security \ gcr.io/google_containers/kube-apiserver:e68c6af15d4672feef7022e94ee4d9af \ kube-apiserver \ --advertise-address=192.168.33.17 \ --admission-control=ServiceAccount \ --insecure-bind-address=0.0.0.0 \ --etcd-servers=http://192.168.33.17:4001 \ --service-cluster-ip-range=11.0.0.0/16 \ --tls-cert-file=/security/server.crt \ --tls-private-key-file=/security/server.key \ --secure-port=443 \ --basic-auth-file=/security/basic_auth.csv \ --insecure-port=0
这样的话,就连取个pod都得这么麻烦:
master
~/kubernetes/server/bin/kubectl -s https://192.168.33.17 --insecure-skip-tls-verify=true --username=admin --password=123456 get po
幸运的是,kubernetes提供了一种方式,让我们可以大大简化命令,只用这样就好了:
master
~/kubernetes/server/bin/kubectl get po
下面就让我们来试一下吧!首先用 kubectl config
命令来配置admin用户:
master
~/kubernetes/server/bin/kubectl config set-credentials admin --username=admin --password=123456
然后是api server的访问方式,给集群起个名字叫qinghua:
master
~/kubernetes/server/bin/kubectl config set-cluster qinghua --insecure-skip-tls-verify=true --server=https://192.168.33.17
接下来创建一个context,它连接用户admin和集群qinghua:
master
~/kubernetes/server/bin/kubectl config set-context default/qinghua --user=admin --namespace=default --cluster=qinghua
最后设置一下默认的context:
master
~/kubernetes/server/bin/kubectl config use-context default/qinghua
然后就可以用我们的简化版啦:
master
~/kubernetes/server/bin/kubectl get po
可以通过以下命令来看到当前kubectl的配置:
master
~/kubernetes/server/bin/kubectl config view
能够看到如下内容:
apiVersion: v1 clusters: - cluster: insecure-skip-tls-verify: true server: https://192.168.33.17 name: qinghua contexts: - context: cluster: qinghua namespace: default user: admin name: default/qinghua current-context: default/qinghua kind: Config preferences: {} users: - name: admin user: password: "123456" username: admin
实际上这些配置都存放在 ~/.kube/config
文件里:
master
cat ~/.kube/config
修改这个文件也可以实时生效。细心的童鞋们可以看到,cluster、context和users都是集合,也就是说如果需要切换用户和集群等,只需要设置默认context就可以了,非常方便。
本文转自掘金-轻松了解Kubernetes认证功能
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Consul + fabio 实现自动服务发现、负载均衡
Consul hashicorp团队开发 就是大名鼎鼎开发 vagrant 的团队。Consul 是一个提供服务发现、健康检测、K/V存储支持分布式高可用多数据中心的服务软件。 比较类似ZooKeeper但又比它多了一些功能。 具体可以参考 Consul和ZooKeeper的区别。 fabio fabio 是 ebay 团队用 golang 开发的一个快速、简单零配置能够让 consul 部署的应用快速支持 http(s) 的负载均衡路由器。 因为 consul 支持服务注册与健康检查所以 fabio 能够零配置提供负载,升级部署从未如此简单。 根据项目的介绍fabio 能提供每秒15000次请求。 有了这两个组件非常容易做服务发现与自动负载均衡, "神器在手、天下我有!" ^ _ ^ 服务发现的特点 服务与服务之间的调用需要在配置文件中填写好主机和端口,不易于维护且分布式环境中不易于部署与扩容。 那么此时就需要考虑服务启动的时候自己把主机和端口以及一些其他信息注册到注册中心,这样其他服务可以从中找到它。 甚至更为简单的注册完毕后通过 DNS 的方式来『寻址』。比如 Zookeepr ...
- 下一篇
Prometheus VS InfluxDB
前言 除了传统的监控系统如 Nagios,Zabbix,Sensu 以外,基于时间序列数据库的监控系统随着微服务的兴起越来越受欢迎,比如 Prometheus,比如 InfluxDB。gtt 也尝试了一下这两个系统,希望能找到两者的差别,为以后选型提供一些帮助。 首先,说道时间序列数据库不得不说老牌的 rrdtools 和 graphite,这些经典老系统工作的非常好,除了有人嫌弃它们在巨大规模情景下不 scale,嫌弃它们部署不方便外。于是有了 OpenTSDB,Prometheus,InfluxDB 等这 些后起之秀。 监控系统 OpenTSDB OpenTSDB:基于 Hadoop and HBase 的时间序列数据库,它最先提出了为 metric 增加 tag(key-value 键值对) 的方法来实现更方便和强大的查询语法,InfluxDB 的设计和查询语法受它的启发很大。OpenTSDB 基于 Hadoop 和 HBase 的实现了变态的横向扩展能力,但是也因为这两个依赖,对于不熟悉 Hadoop 这套系统的团队来说,OpenTSDB 的维护成本很高,于是有人搞出了 Inf...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS6,CentOS7官方镜像安装Oracle11G
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- CentOS关闭SELinux安全模块
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- Hadoop3单机部署,实现最简伪集群
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程