服务账户
服务账户是我们用于身份验证自动化操作的帐户，例如CI/CD流水线。它们不应该与用户绑定，因为如果我们禁用该用户或限制其权限，我们不希望我们的流水线开始失败。服务账户应具有严格的访问控制，并且不应允许执行比管道所需更多的操作，而实际用户可能需要访问更多的资源。
在Argo CD中创建服务账户有两种方法：一种是使用本地用户（只使用apiKey并删除登录部分），另一种是使用项目角色并为这些角色分配令牌。
本地服务账户
现在，我们将创建一个单独的本地帐户，只具有指定的apiKey功能。这样，用户没有UI或CLI的密码，只有在我们为其生成API密钥后才可以访问（从而获得CLI或直接API访问）。我们还将为其设置特定权限；例如，我们将允许其同步特定应用程序。
我们将修改argocd cm ConfigMap以添加新的服务帐户用户，我们将
名称gitops-ci:
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-cm
data:
accounts.alina: apiKey, login
accounts.gitops-ci: apiKey
admin.enabled: "false"
提交并将其推送到远程，以便我们启动并运行新帐户。在我们有了新帐户创建后，我们需要运行一个命令来生成访问令牌。这里的问题是alina用户没有这样做的权限，并且管理员帐户被禁用。我们可以
重新启用管理，但这不是一个好的做法，因为我们可能总是忘记再次禁用它，或者只要长时间保持启用即可。通常，只有在我们完成设置后，我们才应该禁用管理在所有本地用户中。然而，我们可能需要在任何时候创建新的，因为加入我们团队的新人，或通过管道实现自动化的新场景。
所以，让我们看看如何将更新帐户的权限分配给用户alina。为此，我们将修改argocd-rbac-cm.yaml文件，为用户更新创建一个名为role:userupdate的新角色，然后我们将该角色分配给用户（用于定义策略的行以p、 而将用户或组链接到角色的行以g）开头：
apiVersion: v1
kind: ConfigMap
metadata:
name: argocd-rbac-cm
data:
policy.default: role:readonly
policy.csv: |
p, role:user-update, accounts, update, *, allow
p, role:user-update, accounts, get, *, allow
g, alina, role:user-update
提交，将更改推送到远程，并确保 Argo CD 应用它们。 现在，我们可以运行
命令以创建令牌（我们假设您使用 CLI 登录 用户 alina）：
argocd account generate-token -a gitops-ci
输出应该类似于此（它是帐户令牌）：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiIzZTc2NWI5Ny04MG
YyLTRkODUtYTkzYi1mNGIzMjRkYTc0ODciLCJpYXQiOjE2MzQxNDkyODksImlzc
yI6ImFyZ29jZCIsIm5iZiI6MTYzNDE0OTI4OSwic3ViIjoiZ2l0b3BzLWNpOmFw
aUtleSJ9.azbvrvckSDevFOG6Tun9nJV0fEMcMpI9Eca9Q5F2QR4
检查新生成的令牌是否工作的一种简单方法是运行argocd
account获取用户信息命令。我们可以使用登录的用户运行一次，然后使用
验证令牌。在这里，我只为令牌（对于登录的用户
不要传递–auth令牌参数）。–auth令牌标志是一个通用标志，意思是
可以用于任何命令（当然，您会有另一个令牌，所以不要忘记替换它）：
argocd account get-user-info --authtoken eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiIzZTc2NWI5
Ny04MGYyLTRkODUtYTkzYi1mNGIzMjRkYTc0ODciLCJpYXQiOjE2MzQxNDkyODk
sImlzcyI6ImFyZ29jZCIsIm5iZiI6MTYzNDE0OTI4OSwic3ViIjoiZ2l0b3BzLW
NpOmFwaUtleSJ9.azbvrvckSDevFOG6Tun9nJV0fEMcMpI9Eca9Q5F2QR4
输出应类似于此：
Logged In: true
Username: gitops-ci
Issuer: argocd
Groups:
对于新创建的服务帐户，由于我们没有指定任何权限，它将使用默认权限
一个，即只读访问。当然，创建这样一个只具有读取访问权限的令牌并不能
很有道理。通常，它应该做一些事情，比如注册一个新集群或注销它
（这通常是以命令式的方式完成的——通过运行命令），创建或删除用户，创建
应用程序，同步它，等等。我们无法将本地帐户设置为
RBAC组，我们只能有角色并将本地用户分配给角色。我们将看看小组是如何工作的
当我们在本章后面讨论SSO用户时。要获得资源和操作的完整列表，请
可以在RBAC ConfigMap中用于您的本地帐户，您可以查看官方文档：
https://argo-cd.readthedocs.io/en/stable/operator-manual/rbac/#rbacresources-以及行动。
项目角色和令牌
项目角色是我们可以用于服务帐户的第二个选项。应用程序项目是一种方式以便我们对应用程序定义应用一些约束。我们可以从以下位置设置存储库我们获取状态、目标集群以及可以部署甚至筛选的名称空间我们可以安装的资源类型（例如，我们可以声明使用项目无法部署机密）。除此之外，还可以创建项目角色并指定允许执行的操作类型，然后可以为角色分配令牌。
当安装Argo CD时，它还附带了一个默认项目，实际上称为默认项目，即没有对其应用程序设置任何限制（一切都设置为允许：‘*’）。为了展示如何项目与其令牌一起使用，我们将创建一个新项目并将其用于现有的argocd应用一旦我们有了它，我们将需要为项目创建一个角色，为角色，并创建一个令牌。
我们将创建一个名为argocd-proj.yaml的新文件，并将其存储在与argo-app.yaml文件（这些文件也可以在我们的官方回购中找到，网址为https://github.com/PacktPublishing/ArgoCD在ch04/kustomize安装中的实践文件夹）。在我们创建它之后，我们将需要手动应用它（我们将在第5章Argo CD引导中看到K8s集群，应用程序模式如何帮助我们创建所有这些应用程序和应用程序项目自动）。这是目前文件的内容。您可以查看目的地的限制命名空间和集群，并且我们只能从固定的repo加载状态。我们还添加了名为读取和同步的新角色，为此我们允许所有应用程序执行获取和同步操作根据AppProject：
apiVersion: argoproj.io/v1alpha1
kind: AppProject
metadata:
name: argocd
spec:
roles:
- name: read-sync
description: read and sync privileges
policies:
- p, proj:argocd:read-sync, applications, get, argocd/*, allow
- p, proj:argocd:read-sync, applications, sync, argocd/*, allow
clusterResourceWhitelist:
- group: '*'
kind: '*'
description: Project to configure argocd self-manage application
destinations:
- namespace: argocd
server: https://kubernetes.default.svc
sourceRepos:
- https://github.com/PacktPublishing/ArgoCD-in-Practice.git
我们将使用kubectl apply将AppProject应用于集群：
kubectl apply -n argocd –f argocd-proj.yaml
命令输出应类似于以下内容：
appproject.argoproj.io/argocd created
然后，我们将修改argocd应用程序以开始使用这个新的AppProject，从project:默认为定义中的project:argocd。现在，将更新后的文件应用于集群使用kubectl apply（完整的argocd-app.yaml文件可以在https://github.com/PacktPublishing/ArgoCD-in-Practice in ch04/kustomize安装）：
kubectl apply -n argocd -f argocd-app.yaml
现在，我们应该准备好为我们创建的读取和同步角色生成令牌。这需要可以通过CLI或UI以同步方式完成，因此我们可以检索生成的代币我们可以使用用户alina运行CLI命令，但我们会收到一个错误，因为它没有具有所需的权限：
FATA[0000] rpc error: code = PermissionDenied desc = permission denied: projects, update, argocd, sub: alina, iat: 2021-10-16T10:16:33Z
让我们通过修改RBAC ConfigMap来添加所需的权限。我只是在粘贴政策。
csv部分，这一次，我将仅限于我们的确切项目，名为argocd：
policy.csv: |
p, role:user-update, accounts, update, *, allow
p, role:user-update, accounts, get, *, allow
p, role:user-update, projects, update, argocd, allow
g, alina, role:user-update
别忘了提交并将其推送到远程，这样我们的更改就会被Argo CD和应用于群集。之后，我们可以使用以下命令生成令牌
argocd proj role create-token argocd read-sync
回复如下：
Create token succeeded for proj:argocd:read-sync.
ID: ccdc5906-11fc-483b-8e8d-0511c6f28978
Issued At: 2021-10-16T13:44:19+03:00
Expires At: Never
Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiJjY2RjN
TkwNi0xMWZjLTQ4M2ItOGU4ZC0wNTExYzZmMjg5NzgiLCJpYXQiOjE2MzQzODEw
NTksImlzcyI6ImFyZ29jZCIsIm5iZiI6MTYzNDM4MTA1OSwic3ViIjoicHJvajp
hcmdvY2Q6cmVhZC1zeW5jIn0.R02VHylpb4aPjtpd5qLOXHpELGOVgnelCJr3q8
bGU5Y
我现在可以使用此令牌为argocdAppProject下的所有应用程序启动手动同步。
我们只有一个应用程序，它的名称与AppProject相同，argocd。我们可以看到如果我们试图使用登录的用户alina调用sync，我们将得到一个拒绝权限的错误，如下所示 可以在以下命令的输出中看到：
argocd app sync argocd
错误如下：
FATA[0000] rpc error: code = PermissionDenied desc = permission
denied: applications, sync, argocd/argocd, sub: alina, iat:
2021-10-16T10:16:33Z
使用生成的令牌，命令变为：
argocd app sync argocd --auth-token eyJhbGciOiJIUzI1NiIsInR5cCI
6IkpXVCJ9.eyJqdGkiOiJjY2RjNTkwNi0xMWZjLTQ4M2ItOGU4ZC0wNTExYzZmM
jg5NzgiLCJpYXQiOjE2MzQzODEwNTksImlzcyI6ImFyZ29jZCIsIm5iZiI6MTYz
NDM4MTA1OSwic3ViIjoicHJvajphcmdvY2Q6cmVhZC1zeW5jIn0.R02VHylpb4a
Pjtpd5qLOXHpELGOVgnelCJr3q8bGU5Y
输出非常长，因为它开始枚举我们的Argo CD应用程序所拥有的所有资源连同它们的状态一起安装，这意味着同步正在工作。也可以从UI中的同步状态（转到argocd应用程序，在其页面上，您应该有一个同步状态按钮，显示有关上次启动的同步的详细信息）：
我们生成的每个令牌都保存到项目角色中。我们可以检查使用的时间,它的有效期以及是否该轮换它了。如果我们计划的话，我们也可以为它设定一个到期日期在有限的时间内使用它。否则，给我们需要更新的时间设定一个硬性的截止日期会要求管理Argo CD的工程师严格遵守纪律。就我而言，我通常有一种倾向将访问控制的季度审查推迟一到两周，以确定到期日期可能导致管道故障。
注意–仅具有同步操作的令牌让令牌（来自本地帐户或项目角色）只有在我们可以允许应用程序自动同步的情况下才执行同步操作？我认为因此，一个有效的方案是仍然允许应用程序自动同步，但设置
更大的超时，例如10-15分钟（这可以减少系统负载并增加其性能）。然而，在我们向GitOps回购做出承诺后，我们可以调用sync也来自管道。
项目角色只能用于对应用程序的资源和那些应用程序执行操作需要在为其创建角色的项目下，因此其范围非常有限。然而实际上，正是这些限制将它们转化为在我们的管道中使用的良好候选者，因为如果他们因为任何原因受到损害，那么攻击面就会缩小。