Auto-sync: update nexus workspace
This commit is contained in:
@@ -1,62 +1,60 @@
|
||||
---
|
||||
title: "CTP Topic 49 Container Lifecycle Hardening Standards"
|
||||
type: source
|
||||
tags: [Container, Security, Hardening, CTP, Kubernetes, Docker]
|
||||
sources: []
|
||||
last_updated: 2026-04-24
|
||||
tags:
|
||||
- Container
|
||||
- Security
|
||||
- Hardening
|
||||
- Kubernetes
|
||||
- CTP
|
||||
date: 2026-04-14
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards.md]]
|
||||
- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/ctp-topic-49-container-lifecycle-hardening-standards]]
|
||||
|
||||
## Summary（用中文描述）
|
||||
- 核心主题：Micro Focus 产品安全小组（Product Security Group）制定的容器镜像构建阶段（Building）安全加固标准，提供 11 条可操作的安全实践指南。
|
||||
- 问题域：容器镜像构建安全——如何避免引入已知漏洞、敏感信息和错误配置到容器化工作负载中。
|
||||
- 方法/机制：围绕 11 条安全标准逐条说明背景风险（Why）和缓解措施（How），辅以 Kubernetes YAML 配置示例演示。
|
||||
- 结论/价值：为容器镜像构建提供标准化安全基线，配合 Demo 直观展示配置效果，是 [[DevSecOps]] 实践在容器层面的具体落地。
|
||||
- 核心主题：Micro Focus 容器镜像构建安全加固标准，聚焦容器生命周期的构建（Build）阶段
|
||||
- 问题域：企业级 Kubernetes 容器环境的安全基线配置
|
||||
- 方法/机制：11 项安全标准，涵盖基础镜像选择、文件系统权限、进程管理、网络隔离、身份认证等
|
||||
- 结论/价值：提供可落地的容器安全加固实践，配合 Demo 演示验证风险缓解效果
|
||||
|
||||
## Key Claims（用中文描述）
|
||||
- Micro Focus 基础镜像（Micro Focus Base Image）比开源默认镜像更安全——经过安全配置，内置非 root 和非特权（non-root and non-privileged）设置，避免开源默认镜像中的已知漏洞。
|
||||
- 引入 Init 系统（如 [[tini]] / [[tini Init System]]）可防止僵尸进程（Zombie Process）耗尽系统资源——Demo 展示了 [[tini]] 在 Kubernetes 环境中阻止僵尸进程的效果。
|
||||
- 将容器根文件系统设为只读（readOnlyRootFilesystem: true）可阻止攻击者篡改文件系统——Demo 展示了设置该标志后容器内无法创建未授权文件。
|
||||
- 使用 [[Kubernetes Secrets]] 替代将敏感信息硬编码在镜像中——敏感数据应在运行时从 Secret 管理机制获取，而非构建时嵌入镜像。
|
||||
- [[emptyDir Volume]] 用于临时文件系统比主机路径更安全——数据随 Pod 删除自动清理，防止敏感信息残留。
|
||||
- 每个容器仅运行单一应用——防止单个应用被攻陷后干扰同一容器中其他应用的进程。
|
||||
- 设置 automountServiceAccountToken: false 禁用 Kubernetes API 自动挂载——限制被攻陷容器对集群 API 的访问范围，降低权限提升风险。
|
||||
- 使用私有服务账号（Private Service Account）配合精确的 Namespace Role 和 Role Binding——替代默认服务账号，遵循最小权限原则。
|
||||
- 避免使用 hostNetwork 和 hostPort——防止端口冲突和维护网络隔离，减少容器逃逸攻击面。
|
||||
- 使用 Micro Focus 基础镜像可避免开源默认镜像的安全漏洞（配置为安全模式，无可信/非可信组件混合）
|
||||
- 集成 Init 系统（如 tini/teeny）可防止僵尸进程耗尽资源，影响容器稳定性
|
||||
- 设置 readOnlyRootFilesystem=true 可阻止恶意攻击者向容器写入文件
|
||||
- 使用 emptyDir 卷替代 hostPath 可确保 Pod 删除时敏感数据自动清理
|
||||
- 禁用 automountServiceAccountToken 可限制容器被攻破后访问 Kubernetes API 的风险
|
||||
- 每个容器只运行单一应用可防止进程间相互干扰，一个应用被攻破不会影响其他应用
|
||||
- 避免使用 host 网络和 host 端口可维护网络隔离，防止端口冲突
|
||||
|
||||
## Key Quotes
|
||||
> "If one application is compromised process in one application can interfere with the process of other application in the same container." — Ashish, Product Security Group, 说明为何容器应运行单一应用
|
||||
> "Use micro focus base image which are configured to be secure with non and trust weighted components." — Ashish, 说明 Micro Focus 基础镜像的安全配置特性
|
||||
> "teeny prevents zombie processes in Kubernetes." — Ashish, 演示 [[tini]] Init 系统在 Kubernetes 中的作用
|
||||
> "Use Micro Focus base image which are configured to be secure with non and trust weighted components." — Micro Focus 基础镜像安全配置原则
|
||||
> "If one application is compromised process in one application can interfere with the process of other application in the same container." — 单应用容器化原则的原因
|
||||
> "Setting automountServiceAccountToken to false can limit the impact of potential compromises." — Kubernetes API 访问控制
|
||||
|
||||
## Key Concepts
|
||||
- [[Container Lifecycle Hardening]]：容器全生命周期安全加固，涵盖构建（Build）、部署（Deploy）、运行（Run）三个阶段。本视频聚焦构建阶段。
|
||||
- [[tini Init System]]：轻量级 Init 系统，用于容器内正确处理信号和收割僵尸进程，与 [[tini]] 同义。
|
||||
- [[Kubernetes RBAC]]：基于角色的访问控制，通过 Role/RoleBinding/Namespace 机制实现最小权限服务账号管理。
|
||||
- [[Kubernetes Secrets]]：Kubernetes Secret 对象，用于在运行时向容器安全传递敏感信息（如密码、API 密钥），而非将其嵌入镜像。
|
||||
- [[Pod Security Context]]：Pod 安全上下文，定义 Pod 级别的安全设置（如 readOnlyRootFilesystem、automountServiceAccountToken）。
|
||||
- [[emptyDir Volume]]：Kubernetes emptyDir 卷类型，挂载临时文件系统，数据随 Pod 生命周期自动清理。
|
||||
- [[Container Image Scanning]]：镜像漏洞扫描，通过自动化工具识别镜像中的已知安全漏洞并提供修复建议。
|
||||
- [[Kubernetes RBAC]]：Role-Based Access Control，基于角色的访问控制，用于限制 Service Account 对 Kubernetes API 的访问权限。
|
||||
- [[Container Hardening]]：通过配置和策略提升容器安全性的一组最佳实践
|
||||
- [[Read-Only Root Filesystem]]：将容器根文件系统设为只读，防止运行时写入恶意文件
|
||||
- [[Init System in Containers]]：容器内的初始化进程（如 tini/teeny），负责处理信号和回收僵尸进程
|
||||
- [[Kubernetes Security Context]]：Pod/容器级别的安全配置，包括 readOnlyRootFilesystem、automountServiceAccountToken 等
|
||||
- [[Container Image Scanning]]：使用扫描工具识别镜像中的已知漏洞（CVE）
|
||||
- [[Principle of Least Privilege]]：最小权限原则——使用私有服务账号而非默认账号
|
||||
- [[Network Isolation]]：避免 host 网络/端口以维持容器的网络边界隔离
|
||||
|
||||
## Key Entities
|
||||
- [[Ashish]]：Micro Focus Product Security Group 成员，本视频主讲人，负责介绍容器生命周期安全加固标准。
|
||||
- [[Micro Focus]]：企业软件公司，拥有自己的容器基础镜像仓库和安全加固标准体系。
|
||||
- [[Product Security Group]]：Micro Focus 产品安全小组，制定容器安全标准和最佳实践。
|
||||
- [[Kubernetes]]：容器编排平台，是本视频所有安全配置的实施环境。
|
||||
- [[tini]]：容器 Init 系统开源项目，解决容器内僵尸进程和信号转发问题。
|
||||
- [[Ashish]]：Product Security Group 成员，本主题演讲者
|
||||
- [[Micro Focus]]：容器加固标准的制定者，提供安全配置的基础镜像
|
||||
- [[Product Security Group]]：负责制定和维护 Micro Focus 容器安全标准的团队
|
||||
- [[Kubernetes]]：容器编排平台，相关的安全配置包括 ServiceAccount、RBAC、NetworkPolicy
|
||||
|
||||
## Connections
|
||||
- [[ctp-topic-21-supply-chain-security-in-micro-focus]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：供应链安全与容器镜像安全同属 [[DevSecOps]] 范畴，供应链安全关注 CI/CD 过程完整性，容器安全关注镜像内容安全。
|
||||
- [[DevSecOps]] ← extends ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：容器镜像加固是 DevSecOps 在容器领域的具体实践，DevSecOps 强调安全左移（Shift-Left）。
|
||||
- [[ctp-topic-70-eks-deployment-using-iac]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：EKS 部署的容器运行时安全配置与本视频的镜像构建标准互补，共同构成容器全生命周期安全。
|
||||
- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related_to ← [[ctp-topic-49-container-lifecycle-hardening-standards]]：EKS 可靠性最佳实践中的 Pod 安全配置与本视频标准一致。
|
||||
- [[CTP Topic 21 Supply Chain Security in Micro Focus]] ← related_to ← [[CTP Topic 49 Container Lifecycle Hardening Standards]]
|
||||
- [[CTP Topic 37 Secrets Certificates Management]] ← extends ← [[CTP Topic 49 Container Lifecycle Hardening Standards]]（密钥管理是容器安全的一部分）
|
||||
- [[CTP Topic 64 Scaling out with Amazon EKS]] ← depends_on ← [[CTP Topic 49 Container Lifecycle Hardening Standards]]（EKS 运行需要遵循容器加固标准）
|
||||
|
||||
## Contradictions
|
||||
- 与 [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] 的 hostNetwork 配置存在潜在冲突：
|
||||
- 冲突点：Topic 39 中提到 Pod 规范设置 `hostNetwork: true` 以访问内部 Micro Focus 网络和外部资源。
|
||||
- 当前观点（Topic 49）：应避免使用 hostNetwork 以维护网络隔离和防止端口冲突。
|
||||
- 对方观点（Topic 39）：在受限 Lab Landing Zone 网络环境下，hostNetwork 是打通混合网络的必要手段。
|
||||
- 说明：两者的差异源于场景不同——Topic 39 针对的是 IP 地址池不足的受限 Lab 环境，是特例；Topic 49 是通用安全最佳实践，适用于大多数生产场景。
|
||||
- 与 [[Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS]] 可能的冲突：
|
||||
- 冲突点：Bottlerocket OS 使用自己的安全模型，CTP Topic 49 推荐 Micro Focus 基础镜像
|
||||
- 当前观点：企业内使用 Micro Focus 基础镜像进行统一安全管理
|
||||
- 对方观点：Bottlerocket OS 提供原生硬化（hardened）操作系统层，两种方案各有适用场景
|
||||
|
||||
Reference in New Issue
Block a user