本文档采用自动化机器翻译技术翻译。 尽管我们力求提供准确的译文,但不对翻译内容的完整性、准确性或可靠性作出任何保证。 若出现任何内容不一致情况,请以原始 英文 版本为准,且原始英文版本为权威文本。

这是尚未发布的文档。 Admission Controller 1.34-dev.

配置 PolicyServers 使用私有 Sigstore 实例

您可以配置 PolicyServer 使用私有或自托管的 Sigstore 实例进行策略签名验证,而不是使用默认的公共 Sigstore 基础设施。这在隔离环境中或当您操作自己的 Sigstore 部署时非常有用。

先决条件

  • 一个运行中的私有 Sigstore 实例,具有可访问的 Fulcio、Rekor、TSA 和 CT 日志服务

  • kubectl 访问 kubewarden 名称空间

  • 本地安装的 cosign CLI。

  • 本地安装的 jq

步骤 1 - 生成 ClientTrustConfig JSON

PolicyServer 期望一个描述您私有 Sigstore 实例的信任锚和签名配置的 ClientTrustConfig JSON。

获取证书和公钥

从您的私有 Sigstore 实例中检索以下内容:

  • fulcio.pem - Fulcio CA 证书链 (PEM)

  • rekor.pub - Rekor 透明日志公钥

  • tsa.pem - 时间戳授权证书链 (PEM)

  • ctfe.pub - CT 日志公钥

# Fulcio CA certificate chain
curl --fail -o fulcio.pem "${FULCIO_URL}/api/v1/rootCert"

# Rekor transparency log public key
curl --fail -o rekor.pub "${REKOR_URL}/api/v1/log/publicKey"

# Timestamp Authority certificate chain
curl --fail -o tsa.pem "${TSA_URL}/api/v1/timestamp/certchain"

# CT log public key (from the Kubernetes secret in tuf-system namespace)
kubectl get secret -o json -n tuf-system ctlog-public-key \
  | jq -r ".data.public" | base64 -d > ctfe.pub
安全考虑

确保安全地从您的 Sigstore 实例下载证书和密钥。否则,您可能会使用被破坏的数据配置 SUSE Security Admission Controller。

上述命令是如何在测试环境中执行此操作的示例。 请咨询您组织中的相关团队,以了解如何正确获取此信息。

生成受信任的根和签名配置

设置指向您的私有 Sigstore 服务 URL 的环境变量:

export FULCIO_URL=https://fulcio.example.com
export REKOR_URL=https://rekor.example.com
export TSA_URL=https://tsa.example.com
export CTLOG_URL=https://ctlog.example.com
export ISSUER_URL=https://oidc.example.com

运行 cosign 以生成受信任的根:

cosign trusted-root create \
  --fulcio="url=$FULCIO_URL,certificate-chain=fulcio.pem" \
  --rekor="url=$REKOR_URL,public-key=rekor.pub,start-time=2024-01-01T00:00:00Z" \
  --tsa="url=$TSA_URL,certificate-chain=tsa.pem" \
  --ctfe="url=$CTLOG_URL,public-key=ctfe.pub,start-time=2024-01-01T00:00:00Z" \
  --out trusted_root.json

运行 cosign 以生成签名配置:

cosign signing-config create \
  --fulcio="url=$FULCIO_URL,api-version=1,start-time=2024-01-01T00:00:00Z,operator=sigstore.dev" \
  --rekor="url=$REKOR_URL,api-version=1,start-time=2024-01-01T00:00:00Z,operator=sigstore.dev" \
  --rekor-config="ANY" \
  --oidc-provider="url=$ISSUER_URL/auth,api-version=1,start-time=2024-01-01T00:00:00Z,operator=sigstore.dev" \
  --tsa="url=$TSA_URL/api/v1/timestamp,api-version=1,start-time=2024-01-01T00:00:00Z,operator=sigstore.dev" \
  --tsa-config="EXACT:1" \
  --out signing_config.json

--oidc-provider 是可选的。仅在您的私有 Sigstore 实例具有专用 OIDC 提供者时包含此项。如果您的策略是使用 Kubernetes 服务账户令牌(通过 kubectl create token)签名的,请省略此标志。

start-time 值应设置为在您的证书颁发之前的日期(或您的 Sigstore 实例的部署日期)。

有关两个命令的所有可用标志和 JSON 字段定义的完整描述,请参阅 cosign CLI 参考Sigstore 客户端信任配置规范

合并为 trust_config.json

cat << EOF > trust_config.json
{
  "mediaType": "application/vnd.dev.sigstore.clienttrustconfig.v0.1+json",
  "trustedRoot": $(cat trusted_root.json),
  "signingConfig": $(cat signing_config.json)
}
EOF

步骤 2 - 在 kubewarden 名称空间中创建 ConfigMap

ClientTrustConfig JSON 存储在具有键 sigstore-trust-config 的 ConfigMap 中。ConfigMap 必须 位于准入控制器名称空间中。在此示例中为 kubewarden

kubectl --namespace kubewarden create configmap my-sigstore-trust-config \
  --from-file=sigstore-trust-config=trust_config.json

步骤 3 - 创建验证配置 ConfigMap

创建一个 verification_config.yaml 文件,指定您签名策略的证书身份约束。例如,当使用 Kubernetes 服务账户令牌时:

allOf:
  - kind: genericIssuer
    issuer: https://kubernetes.default.svc.cluster.local
    subject:
      equal: https://kubernetes.io/namespaces/<namespace>/serviceaccounts/<serviceaccount>
anyOf: null

<namespace><serviceaccount> 替换为签署策略时使用的名称空间和服务账户。

创建 ConfigMap:

kubectl --namespace kubewarden create configmap my-verification-config \
  --from-file=verification-config=verification_config.yaml

ConfigMap 键 必须verification-config(而不是文件名)。Admission Controller 查找这个确切的键。

步骤 4 - 配置 PolicyServer

在您的 PolicyServer 上设置 spec.sigstoreTrustConfigspec.verificationConfig 为您创建的 ConfigMaps 的名称:

apiVersion: policies.kubewarden.io/v1
kind: PolicyServer
metadata:
  name: default
spec:
  image: ghcr.io/kubewarden/policy-server:latest
  replicas: 1
  sigstoreTrustConfig: my-sigstore-trust-config
  verificationConfig: my-verification-config

控制器将 ConfigMaps 挂载到 policy-server pod 中,并配置它使用您的私有 Sigstore 实例进行签名验证,强制执行验证配置中指定的身份约束。

安全考虑

任何对 sigstoreTrustConfig 引用的 ConfigMap 具有写入权限的用户都可以影响策略签名验证。这可能允许他们替换不同的 Sigstore 信任根并绕过签名检查。

使用 Kubernetes RBAC 限制对该 ConfigMap 的访问,遵循最小权限原则。