diff --git a/.vuepress/config-sidebar.js b/.vuepress/config-sidebar.js index de6910f..3e8aee3 100644 --- a/.vuepress/config-sidebar.js +++ b/.vuepress/config-sidebar.js @@ -397,6 +397,7 @@ module.exports = { title: '安全', collapsable: true, children: [ + 'k8s-advanced/sec/sa-admin', 'k8s-advanced/sec/rbac/api', 'k8s-advanced/sec/rbac/default', 'k8s-advanced/sec/rbac/escalation', diff --git a/.vuepress/public/install-script/kuboard.yaml b/.vuepress/public/install-script/kuboard.yaml index a07670f..140a64e 100644 --- a/.vuepress/public/install-script/kuboard.yaml +++ b/.vuepress/public/install-script/kuboard.yaml @@ -125,6 +125,8 @@ metadata: name: kuboard namespace: kube-system annotations: + k8s.eip.work/displayName: kuboard + k8s.eip.work/workload: kuboard nginx.org/websocket-services: "kuboard" nginx.com/sticky-cookie-services: "serviceName=kuboard srv_id expires=1h path=/" spec: diff --git a/install/install-dashboard.md b/install/install-dashboard.md index 0b7d2f1..b525c4c 100644 --- a/install/install-dashboard.md +++ b/install/install-dashboard.md @@ -35,6 +35,7 @@ Kuboard 是 Kubernetes 的一款图形化管理界面。 | Kubernetes 版本 | Kuboard 版本 | 兼容性 | 说明 | | --------------- | -------------- | ------ | ------------------------------------------------------------ | +| v1.17 | v1.0 | 😄 | 已验证 | | v1.16 | v1.0 | 😄 | 已验证 | | v1.15 | v1.0 | 😄 | 已验证 | | v1.14 | v1.0 | 😄 | 已验证 | diff --git a/learning/k8s-advanced/sec/sa-admin.md b/learning/k8s-advanced/sec/sa-admin.md new file mode 100644 index 0000000..c3b70c4 --- /dev/null +++ b/learning/k8s-advanced/sec/sa-admin.md @@ -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 + + + +本文面向集群管理员，阐述如何管理Service Account。假设您已经熟悉了 [Configure Service Accounts for Pods](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)。 + + + +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。 diff --git a/learning/k8s-intermediate/persistent/volume-mount-point.assets/image-20200101173914313.png b/learning/k8s-intermediate/persistent/volume-mount-point.assets/image-20200101173914313.png new file mode 100644 index 0000000..439d03b Binary files /dev/null and b/learning/k8s-intermediate/persistent/volume-mount-point.assets/image-20200101173914313.png differ diff --git a/learning/k8s-intermediate/persistent/volume-mount-point.md b/learning/k8s-intermediate/persistent/volume-mount-point.md index 1b6b9b0..0b5ba57 100644 --- a/learning/k8s-intermediate/persistent/volume-mount-point.md +++ b/learning/k8s-intermediate/persistent/volume-mount-point.md @@ -54,12 +54,16 @@ spec: ### 通过环境变量指定数据卷内子路径 -**FEATURE STATE：** `Kubernetes v1.15` beta Kuboard暂不支持 +**FEATURE STATE：** `Kubernetes v1.15` beta 使用 `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 ：Kuboard v1.0.6-beta.1 +> +> ![./image-20200101173914313](./volume-mount-point.assets/image-20200101173914313.png) + 如下面的例子，该 Pod 使用 `subPathExpr` 在 hostPath 数据卷 `/var/log/pods` 中创建了一个目录 `pod1`（该参数来自于Pod的名字）。此时，宿主机目录 `/var/log/pods/pod1` 挂载到了容器的 `/logs` 路径： ``` yaml {9,19} diff --git a/support/change-log/change-log-on-the-way.md b/support/change-log/change-log-on-the-way.md index 5062500..9822161 100644 --- a/support/change-log/change-log-on-the-way.md +++ b/support/change-log/change-log-on-the-way.md @@ -1,19 +1,17 @@ Kuboard v1.0.x 的更新说明 -**BUG 修复** - -* 工作负载编辑器 --> Ingress --> 当启用前缀时，Ingress中选择的ServiceName缺少前缀 -* 工作负载编辑器 --> 容器 --> 添加环境变量但不填写时，界面无响应 +## v1.0.6-beta.1 +**新特性** +* 工作负载编辑器 --> 容器信息 --> 挂载点 --> 支持subPathExpr * 日志界面支持 ctrl + F * 更新版本时，可以通过下拉列表选择仓库中的版本号 * 导入导出时，需要支持 nfs 等类型的数据卷 -* subPathExpr https://kuboard.cn/learning/k8s-intermediate/persistent/volume-mount-point.html#%E6%95%B0%E6%8D%AE%E5%8D%B7%E5%86%85%E5%AD%90%E8%B7%AF%E5%BE%84 * 工作负载查看 --> 未显示 SecurityContext * EndPoint @@ -35,7 +33,6 @@ Kuboard v1.0.x 的更新说明 --> clientIP.timeoutSeconds * Service --> .spec.clusterIP -* PV 中支持 hostPath * 存储卷声明去掉分配模式的字段 * 删除容器组时 - graceful period diff --git a/support/change-log/v1.0.x.md b/support/change-log/v1.0.x.md index e97acde..9259380 100644 --- a/support/change-log/v1.0.x.md +++ b/support/change-log/v1.0.x.md @@ -9,10 +9,23 @@ description: 本文描述了Kuboard_v1.0.x的版本变更说明 了解如何 [升级Kuboard](/install/install-dashboard-upgrade.html) -eipwork/kuboard:latest 当前对应的版本是 kuboard v1.0.5.3 +eipwork/kuboard:latest 当前对应的版本是 kuboard v1.0.5.4 Kuboard v1.0.x 的更新说明 +## v1.0.5.4 + +**发布日期** + +2020年1月1日 + +**BUG 修复** + +* 工作负载编辑器 --> Ingress --> 当启用前缀时，Ingress中选择的ServiceName缺少前缀 +* 工作负载编辑器 --> 容器 --> 添加环境变量但不填写时，界面无响应 +* 安装套件 --> 从套件仓库选择套件 --> 点击安装时，不应该所有的套件按钮都显示为加载状态 +* 事件列表 --> 按名称空间删除事件 --> 删除某一个名称空间的事件时，其他名称空间对应的按钮不应该显示为加载状态 + ## v1.0.5.3 **发布日期**