anchore/kubernetes-admission-controller
GitHub: anchore/kubernetes-admission-controller
基于 Anchore Enterprise 的 Kubernetes 动态准入控制器，通过可配置的策略规则在部署时对容器镜像进行安全评估和准入控制。
Stars: 65 | Forks: 28
# Anchore Kubernetes Admission Controller
该控制器基于 [openshift generic admission controller](https://github.com/openshift/generic-admission-server) 构建。
它实现了一个 Kubernetes Dynamic Webhook 控制器，用于与 Anchore 交互，并根据 [Anchore Enterprise](https://www.anchore.com) 在分析期间确定的镜像属性做出准入决策。
Anchore admission controller 支持 3 种不同的操作模式，允许您在环境中调整控制力度与侵入性之间的权衡。
### 严格基于策略的 Admission Gating Mode
这是最严格的模式，仅允许已被 Anchore 分析且在策略评估中获得“pass”的镜像通过准入。这使您能够确保，例如，没有包含已知且有可用修复的高危 CVE 的镜像被部署到集群中，或者其他多种情况。
Anchore 的 [policy language](https://docs.anchore.com/current/docs/overview/concepts/policy/policies/) 支持对镜像属性、漏洞和元数据设置复杂的条件。
在严格准入环境中有用的 Anchore Enterprise 策略规则示例：
* 如果镜像是直接从 dockerhub 拉取的，则拒绝该镜像
* 如果镜像包含有可用修复的高危或严重 CVE，则拒绝该镜像；但如果尚无可用修复，则允许高危漏洞
* 如果镜像包含黑名单包（rpm, deb, apk, jar, python, npm 等），则拒绝该镜像，其中黑名单由您定义
* 永不拒绝来自特定 registry/repository 的镜像（例如，必须允许运行的内部基础设施镜像）
### 基于分析的 Admission Gating Mode
仅允许已被 Anchore 分析和已知的镜像通过准入，但不执行或要求策略评估。这在您希望强制要求所有镜像都通过 CI/CD 流水线部署的情况下非常有用，例如，该流水线本身使用 Anchore 管理镜像扫描，但允许 CI/CD 流程根据镜像或 k8s 本身之外的其他因素决定应运行什么。
### 被动分析触发模式
触发 Anchore 对镜像进行分析，但不阻止镜像的执行（无论分析完成与否或镜像的策略评估结果如何）。这是一种确保所有进入部署阶段（测试、预发布或生产）的镜像都保证拥有某种形式的分析审计记录，并在 Anchore 管理的报告和通知中留有记录的方法。Anchore 中的镜像记录会被添加 "requestor=anchore-admission-controller" 的注解，以帮助追踪其来源。
## 部署
经过测试的控制器部署方式是使用 [Helm Chart](https://github.com/anchore/anchore-charts/tree/main/stable/anchore-admission-controller)，有关其自身配置的更多详细信息，包括让 k8s apiserver 安全连接控制器所需的 tls/cert 设置，请参阅 chart 的 README。
## 环境变量
_CONFIG_FILE_PATH_ - 配置文件的路径。除非设置此变量，否则服务器将使用 _/config.json_。
_ANCHORE_USERNAME_ - Anchore http 客户端的用户名，覆盖配置文件中的值
_ANCHORE_PASSWORD_ - Anchore http 客户端的密码，覆盖配置文件中的值
## 配置文件
控制器使用一对配置文件，以便以不同于配置的方式管理机密信息。
配置由配置文件处理，而 Anchore 用户凭据则从凭据文件中读取，该文件作为挂载的 secret 附加到容器中。
Helm chart 将配置文件挂载在：/config/config.json，凭据挂载在 /credentials/credentials.json
文件的位置可以通过环境变量设置：
CREDENTIALS_FILE_PATH - 凭据列表的完整文件路径，包括文件名（例如 /credentials.json）
CONFIG_FILE_PATH - 配置文件的完整文件路径，包括文件名（例如 /config.json）
### 凭据配置
由于验证请求的映射可能导致评估不同的策略，控制器需要一种方法来获取访问特定策略所需的凭据。凭据配置通过一个 json 文件（通常从 secret 挂载）提供这些信息。
格式为：
```
{
"users": [
{"username": "user1", "password": "password1"},
{"username": "user2", "password": "password2"}
]
}
These must all be valid credentials for the endpoint specified in the configuration
```
### Controller 配置
服务器从 _CONFIG_FILE_PATH_ 位置加载配置（默认为 _/config.json_）
配置是一个 json 文件，包含选择器规则和用于连接 Anchore 的 endpoint，凭据从前一节描述的凭据配置中合并进来。
示例：
```
{
"anchoreEndpoint": "https://anchore-engine-api.anchore.svc.cluster.local:8228",
"validator": {
"enabled": true,
"requestAnalysis": true
},
"selectors": [
{
"selector": {
"resourcetype": "resource",
"selectorkeyregex": "^breakglass$",
"selectorvalueregex": "^true"
},
"policyReference": {
"username": "user1",
"policyBundleId": "application_bundle"
},
"mode": "breakglass"
},
{
"selector": {
"resourcetype": "resource",
"selectorkeyregex": "^app$",
"selectorvalueregex": "^demoapp.*"
},
"policyReference": {
"username": "user1",
"policyBundleId": "application_bundle"
},
"mode": "policy"
},
{
"selector": {
"resourcetype": "namespace",
"selectorkeyregex": "name",
"selectorvalueregex": "^testing$"
},
"policyReference": {
"username": "user1",
"policyBundleId": "test_bundle"
},
"mode": "policy",
},
{
"selector": {
"resourcetype": "image",
"selectorkeyregex": ".*",
"selectorvalueregex": ".*"
},
"policyReference": {
"username": "user1",
"policyBundleId": "default"
},
"mode": "analysis"
}
]
}
```
### Validator 配置详情
* _anchoreEndpoint_ - 发送请求的 API endpoint。可以在运行控制器的集群内部或外部，只要网络上可达即可
* _enabled_ -（当前未使用）布尔值。在未来的更新中，如果为 false，将以类似 dry-run 的模式运行，以启用测试/调试
* _requestanalysis_ - 布尔值。如果设置此选项且上述两个条件不满足（要么设置为 false，要么评估失败），则控制器将请求 Anchore 分析镜像，但不会阻塞等待完成。
### 选择器
* _selector_ - 用于匹配的规则
* _policyReference_ - 如果选择器规则匹配，则使用的策略（带 username 范围）
#### 选择器
* _resourceType_ - 字符串（枚举）："pod"、"namespace" 或 "image" 之一。决定用于选择匹配的元数据
* _selectorKeyRegex_ - 字符串：用于选择名称的正则表达式，或者使用注解/标签与下一个正则表达式进行值比较。对于 pod 和 namespace，值 "name" 会被特殊处理，它将使用实际名称而不是查找键为 "name" 的标签/注解。
* _selectorValueRegex_ - 字符串：用于评估由 selectorKeyRegex 匹配的键值对（注解或标签）的正则表达式
Selector 执行：
对于 namespace 和 pod，当针对元数据评估选择器时，在移至下一条规则之前，每条规则都会先检查所有标签，然后检查所有注解。
对于 pod/namespace 元数据匹配，标签优先于注解。
示例：
选择 pod 所属的 namespace 的名称：
```
"selector": {
"resourceType": "namespace",
"selectorKeyRegex": "name",
"selectorValueRegex": "testing_namespace"
}
```
### 更新配置
控制器会监视配置和凭据文件的更新，并会自动动态重新加载它们，因此无需重启即可更新规则或凭据。
## 开发/测试
对于开发和测试，此仓库提供了一个 [skaffold](https://skaffold.dev) 文件，用于使用 kubernetes-admission-controller chart 进行可重复的测试部署。
[skaffold.yaml](skaffold.yaml) 假设 anchore-admission-controller chart 放置在此仓库根目录下一个名为 `anchore-admission-controller` 的文件夹中。anchore-admission-controller chart 定义在 [anchore-charts repo](https://github.com/anchore/anchore-charts/tree/main/stable/anchore-admission-controller) 中，因此如果您在本地克隆了该仓库，最简单的方法是使用符号链接，例如 `ln -s /path-to-anchore-charts-repo/stable/anchore-admission-controller anchore-admission-controller`
在第一次运行 `skaffold dev/run` 之前，可能需要编辑 [skaffold-values-file.yaml](skaffold-values-file.yaml) 以确保 `anchoreEndpoint` 设置正确，指向您的开发 Enterprise 部署。
标签：Admission Webhook, Anchore, CI/CD安全, Claude, CVE检测, DevSecOps, EVTX分析, Homebrew安装, Llama, OpenShift, Service Implementation, Web截图, 上游代理, 准入控制器, 动态准入控制, 子域名突变, 安全策略, 容器安全, 底层编程, 提示词设计, 日志审计, 活动识别, 测试覆盖率, 镜像分析, 镜像扫描, 镜像策略