本篇我来为你介绍一个我个人很喜欢的，通用策略引擎，名叫 OPA，全称是 Open Policy Agent。
https://www.magalix.com/blog/enforce-pod-security-policies-in-kubernetes-using-opa
前面我们介绍了使用 kube-mgmt 这个 sidecar 容器来完成 OPA 策略的自动同步，此外还有另外一个更加高级的工具 Gatekeeper，相比于之前的模式，Gatekeeper(v3.0) 准入控制器集成了 OPA Constraint Framework，以执行基于 CRD 的策略，并允许声明式配置的策略可靠地共享，使用 kubebuilder 构建，它提供了验证和修改准入控制和审计功能。这允许为 Rego 策略创建策略模板，将策略创建为 CRD，并在策略 CRD 上存储审计结果，这个项目是谷歌、微软、红帽和 Styra 一起合作实现的。
Open Policy Agent 简称 OPA，是一种开源的通用策略代理引擎，是 CNCF 毕业的项目。OPA 提供了一种高级声明式语言 Rego，简化了策略规则的定义，以减轻程序中策略的决策负担。在微服务、Kubernetes、CI/CD、API 网关等场景中均可以使用 OPA 来定义策略。
大型项目中基本都包含有复杂的访问控制策略，特别是在一些多租户场景中，例如Kubernetes中就支持RBAC，ABAC等多种授权类型。Dapr 的 中间件 Open Policy Agent 将Rego/OPA策略应用到传入的Dapr HTTP请求中。
OPA（发音为 “oh-pa”）是一个全场景通用的轻量策略引擎（Policy Engine），OPA 提供了声明式表达的 Rego 语言来描述策略，并将策略的决策 offload 到 OPA，从而将策略的决策过程从策略的执行中解耦。OPA 可适用于多种场景，比如 Kubernetes、Terraform、Envoy 等等，简而言之，以前需要使用到 Policy 的场景理论上都可以用 OPA 来做一层抽象，如下所示：
这是关于Open Policy Agent（OPA）策略语言Rego背后的设计原则的博客系列的第二部分。前面我们描述了如何将Rego的语法设计为反映真实策略的结构。在本系列的这一部分中，我们将了解Rego为什么以及如何专门使用分层数据（例如JSON和YAML）来表示它用于决策和表示决策本身的原始信息。
这两组开源工具都是是基于kubernetes 的webhook机制，支持validatingwebhook和mutatingwebhook。整体思路上是一样的，都是针对资源的字段，如标签、镜像等来设置规则，在对kubernetes资源的控制范围和粒度上，二者可以看作是一样的。
在实际生产环境中，许多场景需要进行策略控制，例如，不同团队的API需要限制访问权限，以避免未经授权的网络访问。为实现这种控制，可以采用策略控制的方法。然而，实施策略控制需要修改代码，而且策略通常很分散。为了解决这个问题，可以使用OPA（Open Policy Agent）进行策略控制。
继续我们的云原生技术走马观花的旅途，这一次我聊一下规则管理Open Policy Agent。相比较来说，这个概念及使用可能并不广范，大多数情况下并无必要使用这个东西，因为它增加了架构与部署的复杂度。
该策略会拒绝disable seccomp的容器运行，策略文件使用rego语言定义规则。
在生产环境中应用 Kubernetes 时，出于安全、合规等管控目的，经常需要对工作负载进行审计、校验以及变更，例如下列场景：
作者：本文将带你初步了解开放策略代理 OPA，一个平台无关的策略执行工具。原文：https://www.magalix.com/blog/introducing-policy-as-code-the-open-policy-agent-opa
作者：Rita Zhang（微软）、Max Smythe（谷歌）、Craig Hooper（澳大利亚联邦银行）、Tim Hinrichs（Styra）、Lachie Evenson（微软）、Torin Sandall（Styra）
Kubernetes 的 Pod Security Policy（PSP）[1] 即将被 淘汰和移除[2]，所以需要找到一个替代方案来填补这个即将出现的空白。目前看来，Kubernetes 自身并没有准备相应的替代方案，因此需要在 Kubernetes 之外寻求解决之道。CNCF 的两个头部项目可能会成为首选的替代产品，它们分别是基于 Open Policy Agent（OPA）的 Gatekeeper 以及 Kyverno，两个产品各行有千秋，但是目前还没有对这两个产品进行过正式的比较，这就让面临选择的用户无从下手了。这两个项目都是全功能的 Kubernetes 策略引擎，因此其功能不仅限于替代 PSP。本文尝试对 Gatekeeper 和 Kyverno 进行一个中立客观的比较，让用户能够据此作出决策。这里仅从 Kubernetes 的视角来对这两个项目来进行评价。
OPA将从外部加载的数据成为基本文档(base documents)，有规则产生的值成为虚拟文档(virtual documents)，此处"虚拟"的意思表示文档由策略进行了计算，且不是外部加载的。Rego中可以使用名为data的全局变量访问这两种数据。
Gatekeeper 是基于 OPA（Open Policy Agent） 的一个 Kubernetes 策略解决方案。在之前的文章中说过，在 PSP/RBAC 等内置方案之外，在 Kubernetes 中还可以通过策略来实现一些额外的管理、安全方面的限制，本文将会从安装开始，介绍几条实用的小策略。
去年这个时候，我们推出了Rego游乐场（Rego Playground）。游乐场提供了一个在线交互环境，用户可以在这里试验和共享OPA策略。
Kubernetes 的 Pod Security Policy（PSP）即将被淘汰和移除，所以需要找到一个替代方案来填补这个即将出现的空白。目前看来，Kubernetes 自身并没有准备相应的替代方案，因此需要在 Kubernetes 之外寻求解决之道。CNCF 的两个头部项目可能会成为首选的替代产品，它们分别是基于 Open Policy Agent（OPA）的 Gatekeeper 以及 Kyverno，两个产品各行有千秋，但是目前还没有对这两个产品进行过正式的比较，这就让面临选择的用户无从下手了。这两个项目都是全功能的 Kubernetes 策略引擎，因此其功能不仅限于替代 PSP。本文尝试对 Gatekeeper 和 Kyverno 进行一个中立客观的比较，让用户能够据此作出决策。这里仅从 Kubernetes 的视角来对这两个项目来进行评价。
我们希望借助本文，让读者了解到如何在 Kubernetes 中使用可信镜像，其中依赖两个著名的 CNCF 开源项目：Notary 和 OPA。主要思路是使用 OPA 策略来定义自己的内容限制策略。
istio 中的授权策略为网格内部的服务提供访问控制。授权策略是快速、强大及被广泛使用的功能，自istio 1.4首次发布以来，我们进行了持续改进，以使策略更加灵活，包含 DENY action, 排除语义, X-Forwarded-For 头支持, 嵌套 JWT claim 支持等，这些功能提高了授权策略的灵活性，但是此模型仍然不支持许多用例，例如：
1、 Visual Studio Code 1.87 发布，编辑器中的语音听写 - 使用你的声音直接在编辑器中听写。对于安装了 VS Code Speech 扩展的用户，可以使用语音直接在编辑器中听写。--vscode社区
关于OPA（Open Policy Agent，开放政策代理），我最喜欢的一点是它可以与其他系统互操作。任何生成JSON的东西 — 现在大多数系统都可以 — 都可以为OPA提供呈现政策判断的输入。由于这种互操作性，你可以将OPA与基于容器的开发工具（如Docker）、基础设施配置工具（如Terraform）、容器编排平台（如Kubernetes）一起使用，而这还只是皮毛。
然后添加下面的策略，它包含一个验证规则，要求所有的 pod 都有一个 app.kubernetes.io/name 标签，Kyverno 支持不同的规则类型来 validate、mutate 和生成配置，策略属性 validationFailureAction 被设置为强制执行，以阻止不合规的 API 请求（使用默认值 audit 会报告违规行为，但不会阻止请求）。
BuildKit 我以前有很多篇文章中都有介绍过了。它是 Docker 的下一代构建引擎，目前在 Docker Desktop 中已经默认启用，在 Docker 的下一个版本 v23.0 中也会默认启用，对 Docker 中构建引擎感兴趣的小伙伴可以查看我之前的 《万字长文：彻底搞懂容器镜像构建 | MoeLove》。
本文所讲的策略，指的是在 Kubernetes 中，阻止特定工作负载进行部署的方法。
在之前的 『K8S生态周报』 和 《搞懂 Kubernetes 准入控制（Admission Controller)》 等文章中，我曾提到过 Kyverno 这个云原生策略引擎项目，很多小伙伴在后台私信我说对这个项目比较感兴趣。这篇文章我们专门来聊聊 Kyverno 吧。
微服务通过将应用程序分解为更小的、独立的部分来提高单个开发团队的生产力。然而，仅使用微服务并不能解决诸如服务发现、身份验证和授权等古老的分布式系统问题。事实上，由于微服务环境的异构性和短暂性，这些问题往往更为严重。
尽管在诞生之初，WebAssembly（简称Wasm）目的是为浏览器带来高级编程的功能 -- 它提供了一条途径，以使得以各种语言编写的代码都可以以接近原生的速度在Web中运行。在这种情况下，以前无法以此方式运行的客户端软件都将可以运行在Web中。
开放策略代理可以通过提供一个完整的工具包来解决Kubernetes授权难题，该工具包用于将声明性策略集成到任意数量的应用程序和基础设施组件中。Kubernetes的强大功能和吸引力在于，与大多数现代API不同，Kubernetes API是基于意图的，这意味着使用它的组织只需要考虑让Kubernetes做什么，而不是他们希望采用Kubernetes如何实现这个目标。
Kubernetes API 服务器是 Kubernetes 控制平面的核心组件之一。该组件暴露 Kubernetes API，并充当控制平面的前端。当用户或进程与 Kubernetes 交互时，API 服务器处理这些请求，并验证和配置 Kubernetes API 对象，如部署或命名空间。当然，这是在 Kubernetes Admission Controllers 的帮助下进行的。那么，什么是 Admission Controller？
在 GItLab CI 中 script 是最常用的关键字，用于指定 Runner 要执行的命令，同时也是除了 trigger[1] 之外所有 Job 都必须包含一个关键字。本文就来介绍 script 关键字的一些实用技巧，帮助您快速、高效地玩转 GItLab CI。
平台工程，即为软件开发构建和管理内部开发者平台的做法，正在迅速流行起来。它的承诺是什么？无缝集成并优化传统的开发和 DevOps 方法，解决其关键差距。
今天，我们将加快进度，来对Provisioning这一层的项目做一下概览。Provisioning层是一种工具性质的项目，能一定程度上提升Kubernetes的综合能力，尤其是镜像管理和安全性。
•初探可编程网关 Pipy•可编程网关 Pipy 第二弹：编程实现 Metrics 及源码解读•可编程网关 Pipy 第三弹：事件模型设计
在前面的一篇文章中我们介绍了如何实现 Kubernetes 的策略管理。下面，让我们了解一下 Kubernetes 开发中的内置策略管理工具。译自 Policy Management in Kubernetes is Changing。
在上一篇 《企业级云原生应用交付及管理系列 - Helm 基础 (一)》 中，我主要介绍了 Helm 的诞生及其发展，包括 Helm 各个版本的情况及社区的发展。
客座文章最初由eficode顾问Michael Vittrup Larsen在eficode博客上发表
该 bug 可能会导致 在使用 Istio 1.6.6 时，某些 Pod 进入 CrashLoopBackOff 状态，无法正常提供服务。
Hello folks! 今天我们介绍一款开源容器平台安全扫描工具 - Kubescape。作为第一个用于测试 Kubernetes 集群是否遵循 NSA-CISA 和 MITREATT&CK 等多个框架安全部署规范的开源工具，Kubescape 在整容器编排生态中具有举足轻重的意义。在这篇文章中，我们将解析什么是 Kubernetes 加固以及如何基于 Kubescape 工具进行 Kubernetes 生态体系加固。
Kubernetes 准入控制器是集群管理必要功能。这些控制器主要在后台工作，并且许多可以作为编译插件使用，它可以极大地提高部署的安全性。
Dapr 允许通过链接一系列中间件组件来定义自定义处理管道。一个请求在被路由到用户代码之前会经过所有定义的中间件组件，然后在返回到客户端之前以相反的顺序经过定义的中间件。
云原生策略执行引擎被高盛、Netflix、Pinterest和T-Mobile等组织用于生产
问卷链接（https://www.wjx.cn/jq/97146486.aspx）
Kubernetes 的安全工具多得很，有不同的功能、范围以及授权方式。因此我们建立了这个 Kubernetes 安全工具列表，其中有来自不同厂商的开源项目和商业平台，读者可以根据兴趣和需要进行了解和选择。
OPA，全称 Open Policy Agent（开放策略代理），官网是 openpolicyagent.org。OPA 主要为了解决云原生应用的访问控制、授权和策略。OPA 是通用的，与平台无关。请求和响应是以 JSON 格式发送的。
Kubernetes 持续发展，提供可以显著增强集群性能、效率和安全性的新功能和优化。对于高级工程师，掌握这些优化可以带来更强大、更可扩展且更具成本效益的部署。以下是 18 个高级 Kubernetes 节点优化的精选列表，按其在 2024 年的预期实用性和受欢迎程度排序。
开放策略代理(Open Policy Agent, OPA)是一种开源的通用策略引擎，它支持跨整个环境中执行统一的上下文感知策略. OPA 是 云原生计算基金会(CNCF)的一个毕业项目。
在项目中， Kubernetes 集群会对 Kubernetes APIServer 的每个请求都进行身份验证和授权管理。在此过程中，授权管理通常由 RBAC 授权模块来实现，但开发者也可以选择其他组件，如 Open Policy Agent（OPA）。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
