Kubernetes10--API访问控制

使用API来访问k8s集群，方便使用第三方客户端来访问和管理k8s集群资源，在此准备使用Java语言来封装API使用。

1.API Server 配置文件解析

如上图所示，k8s集群中主要使用Api Server来作为系统通信的中心，因此使用api相当于主要与api server来进行信息交互。

在此之前使用kubeadm方式来部署k8s集群，查看一下apiserver的yaml文件：

master节点    /etc/kubernetes/manifests/kube-apiserver.yaml

- command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC
    - --advertise-address=192.168.1.15
    - --allow-privileged=true
    - --client-ca-file=/etc/kubernetes/pki/ca.crt
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-cafile=/etc/kubernetes/pki/etcd/ca.crt
    - --etcd-certfile=/etc/kubernetes/pki/apiserver-etcd-client.crt
    - --etcd-keyfile=/etc/kubernetes/pki/apiserver-etcd-client.key
    - --etcd-servers=https://127.0.0.1:2379
    - --insecure-port=0
    - --kubelet-client-certificate=/etc/kubernetes/pki/apiserver-kubelet-client.crt
    - --kubelet-client-key=/etc/kubernetes/pki/apiserver-kubelet-client.key
    - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
    - --proxy-client-cert-file=/etc/kubernetes/pki/front-proxy-client.crt
    - --proxy-client-key-file=/etc/kubernetes/pki/front-proxy-client.key
    - --requestheader-allowed-names=front-proxy-client
    - --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
    - --requestheader-extra-headers-prefix=X-Remote-Extra-
    - --requestheader-group-headers=X-Remote-Group
    - --requestheader-username-headers=X-Remote-User
    - --secure-port=6443
    - --service-account-key-file=/etc/kubernetes/pki/sa.pub
    - --service-cluster-ip-range=10.96.0.0/12
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key

认证模式： authorization-mode=Node,RBAC

apiserver 接口地址： secure-port=6443

安全模式，https服务：证书tls-cert-file=/etc/kubernetes/pki/apiserver.crt   密钥tls-private-key-file=/etc/kubernetes/pki/apiserver.key

开启了boostrap-token认证服务   enable-bootstrap-token-auth=true，后面主要使用该方式进行认证

非安全访问关闭：  insecure-port=0  如果开启不安全  这里由于关闭了http服务，如果开启需要重启apiserver不安全。

默认情况下，Kubernetes API Server在2个端口上提供HTTP：

1. Localhost Port：

    - is intended for testing and bootstrap, and for other components of the master node
      (scheduler, controller-manager) to talk to the API
    - no TLS
    - default is port 8080, change with `--insecure-port` flag.
    - defaults IP is localhost, change with `--insecure-bind-address` flag.
    - request **bypasses** authentication and authorization modules.
    - request handled by admission control module(s).
    - protected by need to have host access
   

2. Secure Port：

    - use whenever possible
    - uses TLS.  Set cert with `--tls-cert-file` and key with `--tls-private-key-file` flag.
    - default is port 6443, change with `--secure-port` flag.
    - default IP is first non-localhost network interface, change with `--bind-address` flag.
    - request handled by authentication and authorization modules.
    - request handled by admission control module(s).
    - authentication and authorisation modules run.

本地主机端口的话只能在集群内部进行访问，kube-proxy可以开启一个代理，但是不能保持长久连接，因此这里使用https访问，使用token认证。

2.API 访问控制

k8s中使用者有普通用户以及Service Account两种，需要进行认证，授权以及访问控制等步骤。

由Kubernetes管理的Service Accounts （服务账户）和（Users Accounts） 普通账户。普通账户是假定被外部或独立服务管理的，由管理员分配keys。在Kubernetes中不能通过API调用将普通用户添加到集群中。相比之下，Service Accounts是由Kubernetes API管理的帐户。它们被绑定到特定的命名空间，并由APIserver自动创建或通过API调用手动创建。Service Accounts与存储为Secrets的一组证书相关联，这些凭据被挂载到pod中，以便集群进程与Kubernetes API通信。

认证：

开启TLS时，所有的请求首先需要认证。Kubernetes支持多种认证机制，并支持同时开启多个认证插件（只要有一个认证通过即可）。如果认证成功，则用户的username会传入授权模块做进一步授权验证；对于认证失败的请求则返回HTTP 401。集群管理器将apiserver配置为运行一个或多个认证器模块。认证模块包含客户端证书，密码、Plain Tokens、Bootstrap Tokens、JWT Tokens（used for service accounts）。可以指定多个认证模块，每个认证模块都会按顺序进行，直到其中一个成功。

授权：

请求必须包含请求者的用户名，请求的操作以及受该操作影响的对象，如果策略已经声明用户具有完成请求的权限，则该请求将被授权。

Kubernetes支持多种授权模块，如ABAC模式、RBAC模式和Webhook模式。当创建集群时，会配置在API Server中使用的授权模块。如果配置了多个授权模块，Kubernetes会检查每个模块，当通过其中任何模块授权请求，则授权成功，如果所有模块都拒绝了该请求，则授权失败（HTTP 403）。

访问控制：

准入控制（Admission Control）用来对请求做进一步的验证或添加默认参数，除了授权模块可用的属性外，准入控制模块还可以访问正在创建或更新对象内容。也可以可以配置多个准入控制器，每个都会按顺序调用。

3. k8s  Bootstrap Tokens 认证

Kubernetes用户可以使用client certificates、bearer tokens、authenticating proxy、HTTP basic auth等认证插件来验证API请求

访问api可以使用普通用户来使用Static Token File认证，这样需要配置api server并且需要重启apiserver 且不支持动态改查。

https://blog.csdn.net/zhd930818/article/details/80026150

在此主要使用Bootstrap Tokens来进行认证：

功能目前为Alpha级别Kubernetes包括一个dynamically-managed的Bearer token类型，称为Bootstrap Token。这些token作为Secret存储在kube-system namespace中，可以动态管理和创建。Controller Manager包含一个TokenCleaner Controller，如果到期时可以删除Bootstrap Tokens Controller。

https://blog.csdn.net/u013073961/article/details/80045927

创建一个Service Account  命名空间 kube-system   

名字admin    角色  ClusterRole   角色绑定  ClusterRoleBinding

kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1beta1
metadata:
  name: admin
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
subjects:
- kind: ServiceAccount
  name: admin
  namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: admin
  namespace: kube-system
  labels:
    kubernetes.io/cluster-service: "true"
    addonmanager.kubernetes.io/mode: Reconcile

生成account:

kubectl create -f admin-token.yaml

查看kube-system令牌，具体令牌介绍http://docs.kubernetes.org.cn/713.html

kubectl get secret -n kube-system

第一个即为刚才创建的令牌：

kubectl describe secret admin-token-tddhx -ns=kube-system

注意token参数，以后api访问需要将token参数至于http  header参数中

4.Bootstrap Tokens访问API Server

curl -k https://192.168.1.15:6443/api/v1/services --header "Authorization: Bearer $token"

-k, --insecure   Allow connections to SSL sites without certs (H)

接下来研究一下：

授权  访问控制原理

api增删改查以及传参等问题

pod node等关键对象的信息获取

 

参考地址：

k8s英文api:

https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.12/

k8s中文说明：

http://docs.kubernetes.org.cn/31.html#Alpha

k8s  java  client  Fabric8:

https://github.com/kubernetes-client/java

其他参考：

https://blog.csdn.net/u013073961/article/details/80045927