rathsted/rathsted-foundations

# Rathsted Foundations Rathsted Foundations 是一个 Kubernetes 基线，专为那些需要在客户、司法管辖区或审计压力下，依然能够控制、解释和捍卫其基础设施的团队而设计。`v1.0.0` 是一个稳定的单节点版本，具有明确的边界：在一个小巧且具有强烈主见的技术栈中实现 GitOps、策略执行、签名构件和 SBOM 生成。它可以帮助团队建立受控的基线，但整体环境的主权仍然取决于您托管它的位置和方式。 ## 适用对象 - 部署到客户自有或受监管环境中的团队 - 需要一个能够向安全部门、采购部门或客户进行解释的基线的运维人员 - 需要一个可提供支持的起点，而不是含糊不清的平台捆绑包的小型团队 ## 实际意义 - 您保留对集群和周围基础设施选择的运营控制权 - 重要的控制点清晰可见：git 托管、CI runner、artifact registry、签名密钥和证据保留 - 仓库明确说明了基线当前的功能与您仍需根据自身环境做出的决定之间的界限 ## 产品简介 - 具有强化默认值的单节点 `k3s` 基线 - Flux GitOps 引导程序 - Kyverno 策略护栏（包括镜像签名验证） - 使用 Syft 生成 SBOM（可选通过 Grype 进行漏洞扫描） - 一个演示工作负载和可选的 app-runtime 配置文件 ## 针对 `1.x` 的产品承诺 - 稳定的、基于标签的单节点基线 - 在 Ubuntu 22.04 和 24.04 上的主要支持路径 - 针对 Debian 12、Rocky Linux 9 和 Ubuntu 24.04 CIS 的验证兼容性路径 - 在注明之处，针对 RHEL 9 和 AlmaLinux 9 提供兼容系列指导 - 确定性的 GitOps 引导和验证流程 - 可以审查、测试和提供证据的策略和供应链控制（有关 Rathsted 参考镜像，请参见[发布签名](docs/release-signing.md)） ## 公共信任 `rathsted-foundations` 旨在作为已发布的 Foundations 基线的公共、可审查的事实来源。公共声明应仅凭公共文件即可提供支持：清单、策略、文档、测试和验证脚本。请参见[公共信任声明](docs/public-trust-statement.md)。 ## 不包含的内容 - 托管 Kubernetes 服务 - 超大规模云服务商克隆 - Serverless 平台 - 多节点 HA 平台 - 认证保证 ## 快速入门 ``` git clone https://github.com/rathsted/rathsted-foundations cd rathsted-foundations make doctor make configure ./bootstrap/install.sh ./bootstrap/verify.sh ``` ## 环境分离 使用两个环境： - 本地工作站：克隆仓库，运行 `make doctor`、`make configure` 和 `make validate-config` - 目标 Linux 主机：在将托管 `k3s` 的机器上运行 `./bootstrap/install.sh` 和 `./bootstrap/verify.sh` k3s 版本在 `install.sh` 中被锁定，上游安装程序会验证 k3s 二进制文件以确保供应链完整性。如果上游安装程序发生变化，请使用 `RATHSTED_K3S_INSTALLER_SHA256` 进行覆盖。 本地工作站可以是 macOS、Linux 或带有 WSL 的 Windows。目标主机是受支持的 Linux 机器。 ## 本地工作站要求 - `bash` - `curl` - `git` - `make` - `python3` - 用于渲染配置验证的 `pyyaml`：`pip install pyyaml` 工作站上的可选项： - 用于本地 registry 流程的 `docker` - 如果您想在本地进行签名/SBOM 工作，需要 `cosign` 和 `syft` ## 目标主机要求 - Ubuntu 22.04 或 24.04（主要） - Debian 12、Rocky Linux 9、RHEL 9、AlmaLinux 9（已测试或兼容） - 最低 4 CPU / 8 GB 内存 / 20 GB 磁盘 - 用于初始引导下载的出站网络访问权限 - 您的部署所需开放的端口，包括用于 Kubernetes API 的 `6443` ## 文档 | 文档 | 涵盖内容 | |----------|---------------| | [快速入门](docs/quickstart.md) | 评估 Foundations 的最快路径，包括工作站与主机的分离及操作系统指导 | | [概述](docs/overview.md) | Foundations 是什么，主权在这里意味着什么，以及产品边界在哪里 | | [架构](docs/architecture.md) | Git、Flux、集群、策略和 registry 的系统图表和控制流视图 | | [策略](docs/policies.md) | 实际执行的基线护栏，包括签名和 registry 策略 | | [策略目录](docs/policy-catalog.md) | 对每个内置策略的通俗易懂的解释，包括其适用场景以及何时可能过于严格 | | [策略编写](docs/policy-authoring.md) | 如何添加或更改策略，以便在验证证据中对其进行执行、测试和表示 | | [策略检查清单](docs/policy-checklist.md) | 用于添加或更改策略而不会跳过测试、文档或验证的操作检查清单 | | [策略例外](docs/policy-exceptions.md) | 何时使用 Kyverno `PolicyException` 以及如何在不削弱整个基线的情况下限定例外范围 | | [合规性映射](docs/compliance-mapping.md) | 仓库控制如何以说明性方式映射到 CIS、NIST 800-53 和 SOC 2 | | [版本](docs/versions.md) | 锁定的组件版本、平台状态以及当前的支持/兼容性矩阵 | | [升级指南](docs/upgrade-guide.md) | 如何在带标签的 `1.x` 版本之间迁移、验证结果并在需要时回滚 | | [配置文件](docs/profiles.md) | 可选的第一阶段运行时配置文件（`app-runtime`）添加了什么以及为何默认关闭 | | [离线说明](docs/offline.md) | 如果您想要离线或仅限本地的引导路径，必须预先准备什么 | | [备份指南](docs/backup-guide.md) | 在单节点部署中需要备份什么，以及恢复功能能做什么和不能做什么 | | [监控指南](docs/monitoring-guide.md) | 推荐的可观测性附加组件，以及为什么监控不在狭窄的基线范围内 | | [事件响应](docs/incident-response.md) | 针对疑似入侵、证据保留、重新安装和轮换的首次响应指导 | | [已知风险](docs/known-risks.md) | 已接受的风险、当前的缓解措施以及仍需运维人员判断的信任边界 | | [管辖区控制矩阵](docs/jurisdiction-control-matrix.md) | 关于集群位置、CI、registry、密钥和证据保留需要询问的业务和运营问题 | | [主权工具链清单](docs/sovereign-toolchain-inventory.md) | 针对 Git、CI、registry、密钥、证据保留和控制平面保管需要捕获的清单字段 | | [运维人员培训检查清单](docs/operator-training-checklist.md) | 在正式推出生产环境或面向审计的使用之前，预期运维人员应掌握的最低知识要求 | | [技术栈](docs/stack.md) | 每个组件对基线的贡献，以及这些部分在实践中是如何组合在一起的 | | [流水线主权](docs/pipeline-sovereignty.md) | CI runner 的位置和保管如何影响整体的管控叙述 | | [Registry 驻留](docs/registry-residency-guide.md) | 如何从默认的示例镜像流程转变为已批准的管辖区内 registry 模型 | | [供应链](docs/supply-chain.md) | 基线中的签名、SBOM 生成和发布验证是如何工作的 | | [发布签名](docs/release-signing.md) | 签名和验证带标签的发布镜像的具体步骤 | | [密钥生命周期](docs/secret-lifecycle.md) | 存在哪些 Foundations 凭据，它们应存放在哪里，以及何时应进行轮换或撤销 | | [安全测试](docs/security-testing.md) | 发布前应运行哪些检查，哪些检查应保留在 CI、夜间或预发布流程中 | | [威胁模型](docs/threat-model.md) | 基线旨在降低哪些风险，以及哪些风险仍超出范围 | | [决策](docs/decisions.md) | 为什么基线使用 Flux、Kyverno 以及当前狭窄的操作模型 | | [公共信任声明](docs/public-trust-statement.md) | 外部审查者应该能够仅从公共仓库中验证什么 | | [兼容性证据](artifacts/) | 来自 `make compat-test` 的每个受支持操作系统的最新验证输出，每次发布时更新 | ## 提议的文档 这些文档是公开的，因为它们解释了策略包管理的预期方向，但它们不是已发布的 `v1.0.0` 运维操作界面的一部分： | 文档 | 存在原因 | |----------|---------------| | [策略包 UX](docs/policy-pack-ux.md) | 提议采用面向包的运维体验，而不是仅靠手动 YAML 进行策略管理 | | [策略包实现](docs/policy-pack-implementation.md) | 概述如何在不进行大规模重构的情况下连接第一个策略包的实现 | | [策略 UI](docs/policy-ui.md) | 提议建立一个仅限本地的 UI，该 UI 将建立在相同的配置和生成的 bundle 模型之上 | ## 仓库布局 | 目录 | 用途 | |-----------|---------| | `bootstrap/` | 完整技术栈的安装、验证和卸载脚本 | | `cluster/` | k3s 配置、GitOps 同步模板、vendored 的 Kyverno 清单 | | `config/` | 由 `make configure` 编写的环境配置 | | `docs/` | 所有文档 — 架构、策略、合规性、升级指南等 | | `examples/` | GitOps 模式示例（`hello-gitops-app`）、客户实例模板 | | `policies/` | Kyverno ClusterPolicies（均为 Enforce 模式） | | `profiles/` | 可选的第一阶段运行时配置文件：`app-runtime`（Traefik + NATS + Postgres） | | `scripts/` | 配置、验证和诊断实用工具 | | `supply-chain/` | Cosign 密钥、SBOM 配置、签名脚本 | | `tests/` | Kyverno 策略测试和负面测试夹具 | | `tools/` | 用于主权状态评估的管辖区扫描 CLI | ## 范围边界 `v1.0.0` 不包含的内容： - 不支持多节点 HA 或灾难恢复 - 不包含密钥生命周期或静态加密（建议使用 SOPS/age） - 除基线 Kubernetes 控制外，无运行时沙箱 - 除内置的 namespace 基线外，无完整的 east-west 网络分段 - 无零预存的离线引导 - 合规性映射是示例性的，不能替代正式评估 - 发布级别的验证需要 registry 可达性 ## 配置模型 `make configure` 会写入 `config/customer.env`，为您的镜像 namespace 渲染 registry/签名策略，并将示例部署指向您选择的镜像。默认演示使用来自 Docker Hub 的 `nginx:1.29.7-alpine` 作为占位符 —— Foundations 不提供自己的应用程序镜像。生产环境使用需要将其替换为您自己的镜像。 ## 配置文件 配置文件是在基线之上叠加的可选工作负载模式。它们默认关闭 —— 仅应用您的部署所需的内容。 | 配置文件 | 命令 | 部署内容 | |---|---|---| | `app-runtime` | `make app-runtime` | Traefik、NATS、Postgres、演示 API —— 标准的 Web/API 工作负载模式 | ## 合规性说明 Foundations 帮助团队制定控制措施、收集证据并建立可重复的发布实践。它本身并不赋予认证、法律批准或监管合规性。 ## 反馈 发现错误或有疑问？[提交 issue](https://github.com/rathsted/rathsted-foundations/issues/new/choose) —— 所有提交均使用结构化模板。

标签：GitOps, LLM防护, PyVis, 基础设施基线, 子域名突变, 应用安全, 策略引擎, 网络安全挑战, 逆向工具