文章采集api(Kubernetes审计策略文件：rules字段用于非资源类型的请求(组图))

　　文章采集api(Kubernetes审计策略文件：rules字段用于非资源类型的请求(组图))

　　Kubernetes 审计功能提供了一组按时间顺序排列的安全相关记录，记录了单个用户、管理员或其他影响系统的系统组件的活动顺序。它可以帮助集群管理员处理以下问题：

　　Kube-apiserver 执行审计。每个执行阶段的每个请求都会生成一个事件，然后根据特定的策略对事件进行预处理并写入后端。

　　每个请求都可以记录一个相关的“阶段”。已知的阶段是：

　　注意：

　　审计日志功能会增加API服务器的内存消耗，因为它需要为每个请求存储审计所需的某些上下文。此外，内存消耗取决于审计日志的配置。

　　审计策略

　　审核政策定义了关于应记录哪些事件以及应收录哪些数据的规则。在处理事件时，会按顺序与规则列表进行比较。第一个匹配规则设置事件的[auditing-level][auditing-level]。已知的审计级别是：

　　**无 -** 符合此规则的日志将不会被记录。

　　**Metadata -** 记录请求的元数据（请求的用户、时间戳、资源、动词等），但不记录请求或响应消息体。

　　**Request -** 记录事件的元数据和请求的消息体，但不记录响应的消息体。这不适用于非资源类型的请求。

　　**RequestResponse -** 记录事件元数据、请求和响应消息正文。这不适用于非资源类型的请求。

　　您可以使用 --audit-policy-file 标志将收录策略的文件传递给 kube-apiserver。如果未设置此标志，则不会记录任何事件。请注意，必须在审核策略文件中提供规则字段。

　　以下是审核策略文件的示例：

　　audit/audit-policy.yaml

　　apiVersion: audit.k8s.io/v1beta1 # This is required.

kind: Policy

# Don't generate audit events for all requests in RequestReceived stage.

omitStages:

- "RequestReceived"

rules:

# Log pod changes at RequestResponse level

- level: RequestResponse

resources:

- group: ""

# Resource "pods" doesn't match requests to any subresource of pods,

# which is consistent with the RBAC policy.

resources: ["pods"]

# Log "pods/log", "pods/status" at Metadata level

- level: Metadata

resources:

- group: ""

resources: ["pods/log", "pods/status"]

# Don't log requests to a configmap called "controller-leader"

- level: None

resources:

- group: ""

resources: ["configmaps"]

resourceNames: ["controller-leader"]

# Don't log watch requests by the "system:kube-proxy" on endpoints or services

- level: None

users: ["system:kube-proxy"]

verbs: ["watch"]

resources:

- group: "" # core API group

resources: ["endpoints", "services"]

# Don't log authenticated requests to certain non-resource URL paths.

- level: None

userGroups: ["system:authenticated"]

nonResourceURLs:

- "/api*" # Wildcard matching.

- "/version"

# Log the request body of configmap changes in kube-system.

- level: Request

resources:

- group: "" # core API group

resources: ["configmaps"]

# This rule only applies to resources in the "kube-system" namespace.

# The empty string "" can be used to select non-namespaced resources.

namespaces: ["kube-system"]

# Log configmap and secret changes in all other namespaces at the Metadata level.

- level: Metadata

resources:

- group: "" # core API group

resources: ["secrets", "configmaps"]

# Log all other resources in core and extensions at the Request level.

- level: Request

resources:

- group: "" # core API group

- group: "extensions" # Version of group should NOT be included.

# A catch-all rule to log all other requests at the Metadata level.

- level: Metadata

# Long-running requests like watches that fall under this rule will not

# generate an audit event in RequestReceived.

omitStages:

- "RequestReceived"

　　您还可以使用最小的审核策略文件来记录元数据级别的所有请求：

　　# Log all requests at the Metadata level.

apiVersion: audit.k8s.io/v1beta1

kind: Policy

rules:

- level: Metadata

　　审核日志后端

　　k8s 目前提供两种日志后端，Log 后端和 webhook 后端。 Log后端可以将日志输出到文件，webhook后端将日志发送到远程日志服务器。目前，只会使用 Log 后端。使用采集进行日志配置和练习。

　　以下实用组件版本docker ce17、k8s 1.9.2

　　您可以使用以下 kube-apiserver 标志来配置日志审核后端：

　　--audit-log-path 指定用于写入审计事件的日志文件路径。不指定此标志将禁用日志后端。 -手段标准化

　　--audit-log-maxage 定义保留旧审计日志文件的最大天数

　　--audit-log-maxbackup 定义要保留的审计日志文件的最大数量

　　–audit-log-maxsize 定义审计日志文件的最大大小（兆字节）

　　目前，我们集群中的 kube-apiserver 组件作为静态 Pod 运行。生命周期由 kubelet 直接管理。静态 pod 是由 kebelet 基于 yaml 文件创建的。 yaml存放路径为/etc/kubernetes/manifests/目录，由kubelet管理的apiserver是基于kube-apiserver.yaml创建的，Log后端需要在kube-apiserver的启动参数中添加如下参数.yaml：

　　--feature-gates=AdvancedAuditing=true

--audit-policy-file=/etc/kubernetes/pki/audit-policy.yaml

--audit-log-format=json

--audit-log-path=/var/log/kubernetes/kubernetes-audit

--audit-log-maxage=30

--audit-log-maxbackup=3

--audit-log-maxsize=100

　　说明：

　　最终配置如下：

　　

　　修改完成后，kubelet会自动删除并重建kube-apiserver的pod（如果pod被删除但几分钟后还没有创建，可以修改-audit-log-maxbackup的值，保存并退出，并等待创建 pod——这可能是一个错误）。重启状态变为running后，可以进入容器查看生成的审计日志文件：

　　

　　查看日志：

　　

　　达到100M后：

　　

　　因为fluentd后面会作为代理来采集日志，所以需要将容器中的日志挂载到宿主机目录，修改kube-apiserver.yaml如下，即/var/log容器中的/kubernetes目录挂载到宿主机的/var/log/kubernetes目录。

　　

　　日志采集

　　目前集群中已经部署了fluentd elasticsearch日志解决方案，所以选择fluentd作为Logging-agent，Elasticsearch作为Logging Backend。集群中的 fluentd-es 作为 DaemonSet 运行。根据DaemonSet的特点，每个Node都应该运行fluentd-es pod，但实际情况是19环境下的三个master节点都没有这个pod。查看名为 fluentd-es-v1.22 的 DaemonSet yaml，可以发现 pod 只会运行在带有 alpha.kubernetes.io/fluentd-ds-ready: "true" 标签的节点上：

　　

　　查看master节点的节点yaml，发现确实没有这个标签。所以需要在master节点节点上加上这个标签：

　　

　　添加标签后，可以看到在docker-vm-6节点上会自动创建pod。

　　Fluentd的配置文件在容器中的/etc/td-agent/td-agent.conf中进行配置，部分配置截图如下：

　　

　　配置由名为 fluentd 的 ConfigMap 指定：

　　

　　可以看到采集和转发审计日志/var/log/kubernetes/kubernetes-audit不会去配置，所以需要在ConfigMap中添加如下配置：

　　

　　添加后截图如下：

　　

　　之后需要重启kube-apiserver节点的fluentd pod。当fluentd采集时，日志也会输出到宿主机的/var/log/fluentd.log，可以看到定位问题的错误日志等信息。如果文件没有审计日志相关的错误，应该将日志发送到logging-backend：elasticsearch，可以通过以下命令进行验证：

　　

　　

　　详细信息如下，记录在审计日志文件中：

　　

　　后续可以使用Kibana进行日志展示。 Elasticsearch、Fluentd、Kibana是著名的EFK日志采集解决方案，ELK等可以根据项目需要选择合适的组件。

　　作者简洁

　　作者：小万堂，爱写认真的小伙，目前维护原创公众号：“我的小万堂”，专注写golang、docker、kubernetes等知识提升硬实力文章，期待你的注意力。转载须知：务必注明出处（注：来自公众号：我的小碗汤，作者：小碗汤）