admin管理员组

文章数量:1648412

版本k8s1.5.2实操

用户账户和用户组

Kubernetes 并不会存储由认证插件从客户端请求中提取出的用户及所属组的信息,它们仅仅用于检验用户是否有权限执行其所请求的操作。客户端访问API服务的途径通常有三种:kubectl、客户端库或者直接使用 REST接口进行请求。而可以执行此类请求的主体也被 Kubernetes 分为两类:现实中的“人”和 Pod 对象, 它们的用户身份分别对应于常规用户 (User Account )和服务账号 ( Service Account) 。Use Account(用户账号):一般是指由独立于Kubernetes之外的其他服务管理的用 户账号,例如由管理员分发的密钥、Keystone一类的用户存储(账号库)、甚至是包 含有用户名和密码列表的文件等。Kubernetes中不存在表示此类用户账号的对象, 因此不能被直接添加进 Kubernetes 系统中 。Service Account(服务账号):是指由Kubernetes API 管理的账号,用于为Pod 之中的服务进程在访问Kubernetes API时提供身份标识( identity ) 。Service Account通常要绑定于特定的命名空间,它们由 API Server 创建,或者通过 API 调用于动创建 ,附带着一组存储为Secret的用于访问API Server的凭据。

 

Kubernetes 有着以下几个内建的用于特殊目的的组 。system:unauthenticated :未能通过任何一个授权插件检验的账号,即未通过认证测 试的用户所属的组 。system :authenticated :认证成功后的用户自动加入的一个组,用于快捷引用所有正常通过认证的用户账号。system : serviceaccounts :当前系统上的所有 Service Account 对象。system :serviceaccounts :<namespace>:特定命名空间内所有的 Service Account 对象。

下面我们来创建一个User Account,测试访问某些我们授权的资源:

创建k8s User Account

一、创建证书

     1.生成创建CA认证中心,ca密钥和ca根证书

ca.key

openssl genrsa -out private/koji_ca_cert.key 2048

ca.crt 



openssl req -config sslf -new -x509 -days 3650 -key private/ca.key -out ca.crt -extensions v3_ca -subj "/O=k8s/CN=admin"

 

     3.创建user私钥

root@localhost:~/.kube # umask 077;openssl genrsa -out admin.key 2048
Generating RSA private key, 2048 bit long modulus
...................................................................................................................+++
.................+++
e is 65537 (0x10001)

 4.创建证书签署请求
 O=组织信息,CN=用户名
 

openssl req -new -key admin.key -out admin.csr -subj "/O=k8s/CN=admin"

5 签署证书

openssl  x509 -req -in admin.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out admin.crt -days 3650

二、创建配置文件

创建配置文件主要有以下几个步骤:

https://blog.csdn/yangbosos/article/details/89392822

kubectl config set-cluster --kubeconfig=/PATH/TO/SOMEFILE      #集群配置
kubectl config set-credentials NAME --kubeconfig=/PATH/TO/SOMEFILE #用户配置
kubectl config set-context    #context配置
kubectl config use-context    #切换context


* --embed-certs=true的作用是不在配置文件中显示证书信息。
* --kubeconfig=/root/cbmljs.conf用于创建新的配置文件,如果不加此选项,则内容会添加到家目录下.kube/config文件中,可以使用use-context来切换不同的用户管理k8s集群。
* context简单的理解就是用什么用户来管理哪个集群,即用户和集群的结合。

 

创建集群配置

1.创建集群

kubectl config set-cluster k8s --server=http://10.10.3.127 --certificate-authority=ca.crt --embed-certs=true

2.创建用户

kubectl config set-credentials admin --client-certificate=admin.crt --client-key=admin.key --embed-certs=true

3.用户和集群关联。上下文环境,可以理解为那个用户对那个集群可以操作

kubectl config set-context admin@k8s --cluster=k8s --user=admin

4.切换context

kubectl config use-context admin@k8s

5.查看

kubectl config view

或者username password方式也可以、

# 创建cluster
kubectl config set-cluster set-cluster k8s --server=http://10.10.3.127 --insecure-skip-tls-verify
# 创建user
kubectl config set-credentials  admin-credentials --username=admin --password=123456aA
# 创建context
kubectl config set-context admin-credentials@k8s  --cluster=k8s --namespace=kube-system --user=admin-credentials
# 指定当前使用的context
kubectl config use-context admin-credentials@k8

 

清空以前的配置

1.kubectl config delete-context admin@k8s
2.kubectl config delete-cluster k8s
3.kubectl config unset  current-context
4.rm -rf ~/.kube/config

三:使用

可以考给其他用户或其他机器上面去

https://blog.csdn/cbmljs/article/details/102953428

root@k8s-master:~# mkdir -p /home/admin/.kube
root@k8s-master:~# cp ~/.kube/config /home/admin/.kube/config
root@k8s-master:~# chown admin.admin -R /home/admin/
root@k8s-master:~# su - admin
admin@localhost:~# kubectl get pod
NAME          STATUS    AGE
10.10.3.119   Ready     4d
10.10.3.183   Ready     4d

 

https://mrbird/Kubernetes-Namespaces-Context.html

可以切换namespace 就不用"-n namespace" ,  kubectl get pods

在一个组织内部,不同的工作组可以在同一个Kubernetes集群中工作,Kubernetes通过命名空间和Context的设置对不同的工作组进行区分,使得它们既可以共享同一个Kubernetes集群的服务,也能够互不干扰。

Namespace的创建

Kubernetes集群会帮我们创建一个名称为default的命名空间:

 

默认情况下,我们的pod、rc、service等Kubernetes资源都是使用这个命名空间,此外我们也可以创建自己的命名空间。

定义一个命名空间配置dev-namesapce.yml:

1
2
3
4
apiVersion: v1
kind: Namespace
metadata:
  name: dev # dev命名空间

 

创建该命名空间:

 

使用Namespace

使用命名空间只需要在创建Kubernetes资源对象的时候指定即可,比如创建一个tomcat-rc.yml,并指定命名空间为dev:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: v1
kind: ReplicationController
metadata:
  name: tomcat-rc
  namespace: dev # 指定命名空间
spec:
  replicas: 2
  selector:
    name: tomcat
  template:
    metadata:
      name: tomcat
      labels:
        name: tomcat
    spec:
      containers:
        - name: tomcat
          image: tomcat
          ports:
            - containerPort: 8080
              hostPort: 8081

 

创建该rc:

可以看到,defalut命名空间下并没有任何pod,而dev命名空间下则有两个tomcat pod实例。

命名空间只是名称上的隔离,不同命名空间下的pod,service等还是可以相互访问的。

Context的创建和使用

我们可以通过创建Context(上下文),指定使用的命名空间,然后使用该Context,来完成默认的命名空间切换。

在创建Context前,我们查看下Kubernetes默认的配置:

可以看到,当前默认的Context名称为kubernetes-admin@kubernetes,由此可以推断,它和defalut这个命名空间挂钩。

创建一个新的Context,名称为ctx-dev,命名空间使用上面创建的dev:

 

其中/root/.kube/config为Kubernetes配置。

创建成功后,我们使用ctx-dev这个Context:

 

可以看到,现在不需要指定-n dev就可以获取到dev命名空间下的pod了,也证实了Context的切换是成功的。

如果想要恢复默认的Context,将Context指定为kubernetes-admin@kubernetes:

 

 

 

 

 

 

 

 

 

 

 

 

 

本文标签: 账号用户K8sUserAccount