【翻译】教程。如何用AWS设置外部秘密

你可能已经看到了，Container Solutions的团队最近宣布了外部秘密社区的诞生，多个人员和组织正在共同努力，在现有项目的基础上创建一个单一的外部秘密解决方案。新的Kubernetes运营商整合了AWS Secrets Manager、HashiCorp Vault、Google Secrets Manager、Azure Key Vault等外部秘密管理系统，旨在实现将秘密从外部API同步到Kubernetes。该项目有大量的文档，当然，它也是开源的!

然而，当涉及到配置提供者和权限时，要知道我们在每个可能的情况下需要做什么并不容易。这一系列的文章将集中讨论如何用不同的提供者设置外部秘密 。本文将探讨如何用AWS SecretsManager设置外部秘密，随后的文章将介绍如何用GCP Secret Manager、Azure KeyVault和Hashicorp Vault设置外部秘密。

为了正确地学习本教程，请确保你已经安装了以下工具。

-awscli 1.20.60版或以上

-minikube- 或任何其他kubernetes集群

- 部署了外部秘密（external-secrets

-jq

此外，在继续学习本指南之前，请确保你已经通过运行aws configure设置了你的cli环境。

程序性认证

External-secrets允许为AWS Secrets Manager提供商配置几种认证方法。本指南将重点介绍程序化认证，因为除了Secrets Manager之外，不需要启动任何AWS资源。

为了做到这一点，我们需要做以下步骤。

1.配置AWS。

a. 创建一个IAM策略；
b. 创建一个IAM组并绑定该策略；
c. 创建一个IAM用户并将其附加到一个组；
d. 为该用户创建证书。

2.配置外部机密

配置AWS

我们首先开始创建一个名为secrets-reader的策略。

POLICY_ARN=$(aws iam create-policy --policy-name secrets-reader --policy-document '{ "Version":"2012-10-17", "声明":[ { "效果":"允许", "行动":["secretsmanager:ListSecrets", "secretsmanager:GetSecretValue" ] ， "资源"。["*" ] } ] }' | jq -r .Policy.Arn)

我们现在创建一个将使用该策略的组。

aws iam create-group --group-name secret-readers aws iam attach-group-policy --policy-arn $POLICY_ARN --group-name secret-readers

接下来，我们创建一个用户名并将其附加到最近创建的组上。

aws iam create-user --user-name external-secrets aws iam add-user-togroup --group-name secret-readers --user-name external-secrets

最后，我们为该用户创建一组凭证，并将其作为秘密添加到kubernetes中。

aws iam create-access-key --user-name external-secrets > creds.json ACCESS_KEY=$(cat creds.json | jq -r .AccessKey.AccessKeyId) SECRET_KEY=$（cat creds.json | jq -r .AccessKey.SecretAccessKey) kubectl create secret generic aws-secret --from-literal=access-key=$ACCESS_KEY --from-literal=secret=$SECRET_KEY

现在，让我们在我们的秘密商店中添加一些秘密吧

aws secretsmanager create-secret /-name super-secret /-secret-string my-custom-secret /-region us-east-2

配置外部秘密

我们需要做的第一件事是定义一个SecretStore。这个资源是所有与后台相关的配置将被存储的地方，以允许外部秘密接触到Secrets-Manager。在这个例子中，我们创建了一个名为my-secret-store的 SecretStore，使用我们在前面步骤中创建的资源。

cat <<EOF | kubectl apply -f - apiVersion: external-secrets.io/v1alpha1 kind: SecretStore metadata: name: my-secret-store spec: provider: aws:  # 设置secretStore提供商为AWS。SecretsManager # 配置服务为Secrets Manager region: us-east-2 # 秘密所在的区域。 auth: secretRef: accessKeyIDSecretRef: 
            name: aws-secret # 引用我们创建的秘密 key: access-key secretAccessKeySecretRef: name: aws-secret key: secret EOF

下一件事是创建一个ExternalSecret定义。在这个定义中，我们将指出哪些秘密来自SecretStore，我们希望将其同步到Kubernetes Secrets对象中。下面是一个名为my-external-secret的ExternalSecret的例子，它获得了我们在AWS Secrets Manager中创建的秘密。

cat <<EOF | kubectl apply -f - apiVersion: external-secrets.io/v1alpha1 kind:ExternalSecret metadata: name: my-external-secret spec: refreshInterval: 1m secretStoreRef: name: my-secret-store #我们刚刚创建的秘密存储名称。 kind: SecretStore target: name: my-kubernetes-secret # k8s中的秘密名称 data: - secretKey: password #它将被存储的钥匙 remoteRef: key: super-secret # 我们的秘密名称放在这里 EOF

就这样了!你可以看到，一个名为 "my-kubernetes-secret "的秘密在kubernetes中被external-secrets操作者创建。我们可以通过键入来评估该秘密值。

kubectl get secrets my-kubernetes-secret -o json | jq -r .data.password | base64 -d

我们还可以通过以下命令行来检查ExternalSecret的状态。

kubectl get externalsecrets.external-secrets.io my-external-secret NAME STORE REFRESH INTERVAL STATUS my-external-secret My-secret-store 1m SecretSynced

添加更好的政策和适当的角色

上面的例子是一个很好的、简单的演示，但它还没有完全为生产做好准备。首先，我们创建的策略secrets-reader并没有强制执行。它允许外部秘密从AWS秘密管理器中获取任何信息。虽然这对小型部署来说可能是有效的，但生产就绪的环境需要对特定账户可以访问的资源有更严格的要求。实施这种限制的一种方法是遵循最小特权原则。在这次会议上，我们将展示如何配置AWS策略来实现这一目标。

但首先，让我们增加一些秘密，以便我们可以测试策略的效果。

aws secretsmanager create-secret \ --name another-secret \ --secret-string this_is_another_secret \ --region us-east-2 aws secretsmanager create-secret \ --name forbidden-secret \ --secret-string "我们不会看到这个" \ --region us-east-2

我们需要做的第一件事是创建一个更严格的政策。为了做到这一点，我们唯一需要做的是添加特定的资源，而不是一般的 "*"策略。下面这个例子创建了一个策略，允许访问超级机密 和另一个机密，但不允许访问禁止的机密。

STRICT_POLICY_ARN=$(aws iam create-policy --policy-name strict-policy --policy-document '{ "Version":"2012-10-17", "声明":[ { "效果":"允许", "行动":["secretsmanager:ListSecrets", "secretsmanager:GetSecretValue" ] ，"资源"。["arn:aws:secretsmanager:us-east-2:<YOUR_ACCOUNT_ID>:secret:super-secret-<foobar>", "arn:aws:secretsmanager:us-east-2:<YOUR_ACCOUNT_ID>:secret:another-secret-<foobar>" ] ] }' | jq -r . Policy.Arn)

注意：请记住用适当的值替换你的方案中的秘密ARN!你可以用以下命令检查秘密ARN。

aws secretmanager list-secrets --region us-east-2

现在，让我们分离旧策略并附加这个新策略。

aws iam detach-group-policy --policy-arn $POLICY_ARN --group-name secret-readers aws iam attach-group-policy --policy-arn $STRICT_POLICY_ARN --group-name secret-readers

最后，让我们再创建两个ExternalSecret对象：一个用于另一个external-secret，一个用于 bidden-secret。

cat <<EOF | kubectl apply -f - apiVersion: external-secrets.io/v1alpha1 kind:ExternalSecret metadata: name: another-external-secret spec: refreshInterval: 1m secretStoreRef: name: my-secret-store kind: SecretStore target: name: another-kubernetes-secret data: - secretKey: key-in-kubernetes remoteRef: key: another-secret EOF/pre>

cat <<EOF | kubectl apply -f - apiVersion: external-secrets.io/v1alpha1 kind:ExternalSecret metadata: name: invalid-permissions spec: refreshInterval: 1m secretStoreRef: name: my-secret-store kind: SecretStore target: name: should-not-becreated data: - secretKey: wont-becreated remoteRef: key: forbidden-secret EOF

就这样了!如果我们看一下ExternalSecret的状态，我们会看到。

kubectl get external-secrets NAME STORE REFRESH INTERVAL STATUS another-external-secret my-secret-store 1m SecretSynced invalid-permissions my-secret-store 1m SecretSyncedError my-external-secret my-secret-store 1m SecretSynced

这表明我们的invalid-permissions资源确实不能访问forbidden-secret!

总结

在这篇文章中，我们已经看到了如何配置AWS和外部秘密，以允许使用Secrets Manager作为提供者。如果你在EKS集群上运行，还有其他支持的认证方法。你可以在官方的external-secrets文档中查看。

总结一下我们所做的事情。

• 在AWS中创建IAM资源
• 在Secrets Manager中创建secrets
• 创建SecretStore和ExternalSecrets
• 完善AWS IAM策略

在下一篇文章中，我们将看到如何将GCP Secret Manager配置为SecretStore!请继续关注!