subPathExpr / ServiceAccount
This commit is contained in:
huanqing.shao
95
learning/k8s-advanced/sec/sa-admin.md
Normal file
95
learning/k8s-advanced/sec/sa-admin.md
Normal file
@ -0,0 +1,95 @@
|
||||
---
|
||||
vssueId: 175
|
||||
layout: LearningLayout
|
||||
description: Kubernetes教程_本文面向集群管理员，阐述如何管理Service Account。Kubernetes 已经计划了要支持 user account，但是尚未完成。本文中引用了未完成的特性（user account）是为了更好地描述 service account。
|
||||
meta:
|
||||
- name: keywords
|
||||
content: Kubernetes 教程,Kubernetes Service Account
|
||||
---
|
||||
|
||||
# 管理ServiceAccount
|
||||
|
||||
<AdSenseTitle/>
|
||||
|
||||
本文面向集群管理员，阐述如何管理Service Account。假设您已经熟悉了 [Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)。
|
||||
|
||||
<!-- FIXME -->
|
||||
|
||||
Kubernetes 已经计划了要支持 user account，但是尚未完成。本文中引用了未完成的特性（user account）是为了更好地描述 service account。
|
||||
|
||||
[[TOC]]
|
||||
|
||||
## User accounts vs. service accounts
|
||||
|
||||
|
||||
Kubernetes 明确地区分了 user account 和 service account 的概念，原因如下：
|
||||
|
||||
* User account 的使用者是用户（人），service account 的使用者是运行在 Pod 中的进程。
|
||||
* User account 应该是全局的，用户名在集群范围内（跨名称空间）必须唯一。Service account 的名称在名称空间内唯一即可
|
||||
* 通常，集群的 user account 可能是从企业的数据库同步过来，在那里，创建新的 user account 需要特殊的权限，并且受复杂的业务流程管控。Service account 的创建则更加轻量级，允许集群的用户为特定的任务创建 service account，（最小权限的原则）
|
||||
* 对用户（人）和 service account 的审计过程可能会不一样
|
||||
* 一个复杂系统中，可能为不同的组件配置不同的 service account。由于 service account 可以临时创建，并且在名称空间内唯一，这种配置信息是可以移植的
|
||||
|
||||
## Service account automation
|
||||
|
||||
三个组件共同实现了 service account 的 automation：
|
||||
* Service account admission controller
|
||||
* Token controller
|
||||
* Service account controller
|
||||
|
||||
### Service account admission controller
|
||||
|
||||
[Admission Controller](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/) 是 apiserver 的一部分，它在 Pod 创建或者更新时，对 Pod 执行一些修改。此控制器激活时（默认处于激活状态），当 Pod 被创建或修改时，该控制器将执行如下动作：
|
||||
1. 如果 Pod 未设置 `ServiceAccount`，将 `ServiceAccount` 设置为 `default`
|
||||
2. 确保 Pod 引用的 `ServiceAccount` 存在，否则拒绝创建或者修改 Pod
|
||||
3. 如果 Pod 不包含任何 `ImagePullSecrets`，则 `ServiceAccount` 中的 `ImagePullSecrets` 将被添加到 Pod 上
|
||||
4. 为 Pod 添加一个 `volume` （其中包含了访问 APIServer 的 token）
|
||||
5. 为 Pod 中的每一个容器添加一个 `volumeSource`，并挂载到路径 `/var/run/secrets/kubernetes.io/serviceaccount`
|
||||
|
||||
自 v1.13 开始，当 `BoundServiceAccountTokenVolume` 特性被启用时，可以将 service account volume 迁移到一个 [projected volume](https://kubernetes.io/docs/tasks/configure-pod-container/configure-projected-volume-storage/)。Service account token 将在一小时后或者 Pod 被删除后过期。
|
||||
|
||||
### Token Controller
|
||||
|
||||
TokenController 作为 controller-manager 的一部分运行。以异步的方式执行如下动作：
|
||||
|
||||
* 监听 ServiceAccount 的创建，并创建一个对应的 Secret 以允许访问 APIServer
|
||||
* 监听 ServiceAccount 的删除，并删除所有对应的 ServiceAccountToken Secrets
|
||||
* 监听 Secret 的添加，确保其引用的 ServiceAccount 以存在，并在需要时向 Secret 添加 Token
|
||||
* 监听 Secret 的删除，并在需要的情况下将对应 ServiceAccount 中对 Secret 的引用也删除掉
|
||||
|
||||
启动 controller-manager 时，必须通过 `--service-account-private-key-file` 参数，向 token controller 传递一个 service account private key 文件。该 private key 将用来为沈城的 service account token 签名。类似的，也必须为通过 `--service-account-key-file` 将其对应的 public key 传递给 kube-apiserver。该 public key 将被用来在认证时验证 token。
|
||||
|
||||
#### 创建额外的 API token
|
||||
|
||||
控制器确保每个 Service account 都有一个包含 API token 的 Secret。如需为 Service Account 创建额外的 API token，可以创建一个类型为 `ServiceAccountToken` 的 Secret，并在注解中引用对应的 Service Account，此时，控制器将为其创建一个新的 token：
|
||||
|
||||
> secret.json
|
||||
|
||||
``` json
|
||||
{
|
||||
"kind": "Secret",
|
||||
"apiVersion": "v1",
|
||||
"metadata": {
|
||||
"name": "mysecretname",
|
||||
"annotations": {
|
||||
"kubernetes.io/service-account.name": "myserviceaccount"
|
||||
}
|
||||
},
|
||||
"type": "kubernetes.io/service-account-token"
|
||||
}
|
||||
```
|
||||
|
||||
``` sh
|
||||
kubectl create -f ./secret.json
|
||||
kubectl describe secret mysecretname
|
||||
```
|
||||
|
||||
#### 删除/禁用 Service Account token
|
||||
|
||||
``` sh
|
||||
kubectl delete secret mysecretname
|
||||
```
|
||||
|
||||
### Service Account Controller
|
||||
|
||||
Service Account Controller 管理了名称空间中的 ServiceAccount，并确保每一个当前有效的名称空间中都存在一个名为 `default` 的 ServiceAccount。
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 10 KiB |
@ -54,12 +54,16 @@ spec:
|
||||
|
||||
### 通过环境变量指定数据卷内子路径
|
||||
|
||||
**FEATURE STATE：** `Kubernetes v1.15` <Badge type="warning">beta</Badge> <Badge type="error">Kuboard暂不支持</Badge>
|
||||
**FEATURE STATE：** `Kubernetes v1.15` <Badge type="warning">beta</Badge>
|
||||
|
||||
使用 `volumeMounts.subPathExpr` 字段，可以通过容器的环境变量指定容器内路径。使用此特性时，必须启用 `VolumeSubpathEnvExpansion` [feature gate](https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/) （自 Kubernetes v1.15 开始，是默认启用的。）
|
||||
|
||||
同一个 volumeMounts 中 `subPath` 字段和 `subPathExpr` 字段不能同时使用。
|
||||
|
||||
> 在Kuboard界面中，如果工作负载编辑器中挂载点的 subPath/subPathExpr 字段中包含 `$`，则 Kuboard 认为该字段为 subPathExpr，否则被认为是 subPath。例如，下图中的 $(podName) 将被认为是 subPathExpr ：<Badge type="default">Kuboard v1.0.6-beta.1</Badge>
|
||||
>
|
||||
> 
|
||||
|
||||
如下面的例子，该 Pod 使用 `subPathExpr` 在 hostPath 数据卷 `/var/log/pods` 中创建了一个目录 `pod1`（该参数来自于Pod的名字）。此时，宿主机目录 `/var/log/pods/pod1` 挂载到了容器的 `/logs` 路径：
|
||||
|
||||
``` yaml {9,19}
|
||||
|
||||
Reference in New Issue
Block a user