设为首页 收藏本站
查看: 1063|回复: 0

[经验分享] Kubernetes-Service Account

[复制链接]

尚未签到

发表于 2018-1-4 16:38:05 | 显示全部楼层 |阅读模式

  • kube-apiserver
  配置文件:/etc/kubernetes/apiserver
  KUBE_API_ADDRESS="--insecure-bind-address=0.0.0.0"
  KUBE_API_PORT="--port=8080"
  KUBE_ETCD_SERVERS="--etcd-servers=http://127.0.0.1:2379"
  KUBE_SERVICE_ADDRESSES="--service-cluster-ip-range=10.254.0.0/16"
  KUBE_ADMISSION_CONTROL="--admission-control=NamespaceLifecycle,NamespaceExists,LimitRanger,SecurityContextDeny,ResourceQuota,ServiceAccount"
  KUBE_API_ARGS=""

Configure Service Accounts for Pods
  ServiceAccount给运行在Pod中的进程提供一个身份。
  若要详细了解,需要参考文档https://kubernetes.io/docs/admin/service-accounts-admin/
  注:这篇文章描述了ServiceAccount在Kubernetes集群中的表现方式。你的集群管理员可能有自定义的表现在你自己的集群中,所以在某些情景下面,这篇文档并不符合。
  当你可以进入到集群(kubectl),你将被apiserver认定为一个特殊的用户(admin,除非你的集群管理员有自定义了集群的某些设置),在Pod中的容器中的进程也可以与apiserver通信,当他们通信的时候,他们将被认定为一个特殊的ServiceAccount(default)。

Use the Default Service Account to access the API server
  当你创建一个Pod并没有指定一个service account,它将自动的为Pod在相同的namespace中分配default service account。当你截取你所创建的Pod信息为json或yaml格式输出(例如:kubectl get pods/podname -o yaml ),你将会看到spec.serviceAccountName字段被自动的设置。
  Pod可以使用自动挂载的service account凭证来获取访问API的权限,就如在访问集群的时候一样。service account的权限取决于在用的认证插件及策略。
  在1.6版本以后,你可以通过设置automountServiceAccountToken:false对某个service account不加载API凭证:
  apiVersion: v1
  kind:ServiceAccount
  metadata:
  name:build-robot
  automountServiceAccountToken:false
  在1.6版本之后,你可以选择不加载API凭据到一个特殊的Pod中:
  apiVersion:v1
  kind:Pod
  metadata:
  name:my-pod
  spec:
  serviceAccountName:build-robot
  automountServiceAccountToken:false
  如果在Pod和ServiceAccout中均设置的automountServiceAccountToken,在Pod的sepc中设置的优先于在service account。

Use Multiple Service Accounts
  每一个namespace都有一个默认的service account(default),可以通过如下命令来列出相应namespace下的所有service account:


  • kubectl get serviceAccount
  你也可以创建额外的ServiceAccount如:


  • cat serviceaccount.yaml
  apiVersion:v1
  kind:ServiceAccount
  metadata:
  name:build-robot


  •     kubectl create -f serviceaccount.yaml
  如果你查看一个完整的serviceaccount,如下:
  

$ kubectl get serviceaccounts/build-robot -o yaml  
apiVersion: v1
  
kind: ServiceAccount
  
metadata:
  creationTimestamp: 2015-06-16T00:12:59Z
  name: build-robot
  namespace: default
  resourceVersion: "272500"
  selfLink: /api/v1/namespaces/default/serviceaccounts/build-robot
  uid: 721ab723-13bc-11e5-aec2-42010af0021e
  
secrets:
  
- name: build-robot-token-bvbk5
  

  通过上面的信息就可以发现,一个令牌被自动创建生成并被ServiceAccount引用。
  你也可以通过认证插件来设置service account的权限。
  如果你不想使用默认的service account,只需要在spec.serviceAccountName字段设置你想使用的serviceaccount的名字就可以了。
  可以通过如下命令对serviceaccount进行清除:


  • kubectl delete serviceaccount/build-robot
Manaually create a service account API token
  假如有一个已经存在的service account叫“build-robot”,我们手动创建一个新的secret。


  • cat build-robot-secret.yaml
  apiVersion: v1
  kind:Secret
  metadata:
  name:build-robot-secret
  annotations:
  kubernetes.io/service-account.name:build-robot
  type:kubernetes.io/service-account-token


  • kubectl create -f build-robot-secret.yaml
  现在你可以确认新构建的secret使用了build-robot的service account的API令牌。
  不存在的service account的任何令牌都将被令牌控制器清理。


  • kubectl describe secrets/build-robot-secret
  

$ kubectl describe secrets/build-robot-secret  
Name:           build-robot-secret
  
Namespace:      default
  
Labels:         <none>
  
Annotations:    kubernetes.io/service-account.name=build-robot
  kubernetes.io/service-account.uid=da68f9c6-9d26-11e7-b84e-002dc52800da
  

  
Type:   kubernetes.io/service-account-token
  

  
Data
  
====
  
ca.crt:         1338 bytes
  
namespace:      7 bytes
  
token:          ...
  

  注:此处令牌的内容被省略

Add ImagePullSecret to a service account
  首先创建一个imagePullSecret,然后再验证他被创建。


  • kubectl get secrets myregistrykey
  • kubectl patch serviceaccount default -p ‘{“imagePullSecrets”:[{"name":myregistrykey}]}’
  上面的命令则是修改一个namespace默认的service account,使其用这个secret作为一个imagePullSecret。
  互动版本需要手动编辑:


  • kubectl get serviceaccounts default -o yaml > ./sa.yaml
  • cat sa.yaml
  apiVersion: v1
  kind: ServiceAccount
  metadata:
  creationTimestamp: 2017-11-20T22:23:33Z
  name: default
  namespace: default
  resourceVersion: "243024"
  selfLink: /api/v1/namespace/default/serviceaccounts/default
  uid: 3ee3453r-3erfd-112e-33rf-dfgt5678ujyh
  secrets:
  - name: default-token-uudge


  • vi sa.yaml
[editor session not shown]

[delete line with key "resourceVersion"]

[add lines with "imagePullSecret:"]



  • cat sa.yaml
  apiVersion: v1
  kind: ServiceAccount
  metadata:
  creationTimestamp: 2017-11-20T22:23:33Z
  name: default
  namespace: default
  resourceVersion: "243024"
  selfLink: /api/v1/namespace/default/serviceaccounts/default
  uid: 3ee3453r-3erfd-112e-33rf-dfgt5678ujyh
  secrets:
  - name: default-token-uudge
  imagePullSecrets:
  - name: myregistrykey
  在这个namespace中任何创建的新的pods将会加上这个imagePullSecrets。
  spec:
  imagePullSecrets:
  - name: myregistrykey

运维网声明 1、欢迎大家加入本站运维交流群:群②:261659950 群⑤:202807635 群⑦870801961 群⑧679858003
2、本站所有主题由该帖子作者发表,该帖子作者与运维网享有帖子相关版权
3、所有作品的著作权均归原作者享有,请您和我们一样尊重他人的著作权等合法权益。如果您对作品感到满意,请购买正版
4、禁止制作、复制、发布和传播具有反动、淫秽、色情、暴力、凶杀等内容的信息,一经发现立即删除。若您因此触犯法律,一切后果自负,我们对此不承担任何责任
5、所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其内容的准确性、可靠性、正当性、安全性、合法性等负责,亦不承担任何法律责任
6、所有作品仅供您个人学习、研究或欣赏,不得用于商业或者其他用途,否则,一切后果均由您自己承担,我们对此不承担任何法律责任
7、如涉及侵犯版权等问题,请您及时通知我们,我们将立即采取措施予以解决
8、联系人Email:admin@iyunv.com 网址:www.yunweiku.com

所有资源均系网友上传或者通过网络收集,我们仅提供一个展示、介绍、观摩学习的平台,我们不对其承担任何法律责任,如涉及侵犯版权等问题,请您及时通知我们,我们将立即处理,联系人Email:kefu@iyunv.com,QQ:1061981298 本贴地址:https://www.yunweiku.com/thread-431574-1-1.html 上篇帖子: Kubernetes Scheduler原理解析 下篇帖子: Kubernetes Running Locally
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

扫码加入运维网微信交流群X

扫码加入运维网微信交流群

扫描二维码加入运维网微信交流群,最新一手资源尽在官方微信交流群!快快加入我们吧...

扫描微信二维码查看详情

客服E-mail:kefu@iyunv.com 客服QQ:1061981298


QQ群⑦:运维网交流群⑦ QQ群⑧:运维网交流群⑧ k8s群:运维网kubernetes交流群


提醒:禁止发布任何违反国家法律、法规的言论与图片等内容;本站内容均来自个人观点与网络等信息,非本站认同之观点.


本站大部分资源是网友从网上搜集分享而来,其版权均归原作者及其网站所有,我们尊重他人的合法权益,如有内容侵犯您的合法权益,请及时与我们联系进行核实删除!



合作伙伴: 青云cloud

快速回复 返回顶部 返回列表