v2.3 至 2.4¶

已知问题¶

2.4.27 之前已损坏的 `project` 过滤器¶

Argo CD 2.4.0 引入了一个突破性的 API 更改，将 "项目 "过滤器更名为 "项目"。

对应用程序接口客户的影响¶

类似的问题也适用于通过 REST API 与 Argo CD API 服务器通信的其他 API 客户端。如果客户端使用 "项目 "字段来过滤项目，则过滤器将不会被引用。 项目过滤器失效可能会产生有害后果，例如，如果您依赖它来列出要删除的应用程序。

对 CLI 客户的影响¶

v2.4.0 以上版本的 CLI 客户端依靠客户端过滤，不受此错误的影响。

如何解决问题¶

升级到 Argo CD >=2.4.27、>=2.5.15 或 >=2.6.6。此版本的 Argo CD 将同时接受 project 和 projects 作为有效过滤器。

移除 KSonnet 支持¶

Ksonnet 已于 2019 过时，不再维护。现在是时候将它从 Argo CD 中删除了。

移除对 Helm 2 的支持¶

Helm 2 自 2020 年 11 月起不再受官方支持。为了确保平稳过渡，Argo CD 中保留了 Helm 2 支持。我们认为 Helm 3 已经稳定，是时候放弃 Helm 2 支持了。

删除了对使用 SHA-1 签名散列算法的私有 repo SSH 密钥的支持¶

注：此更改已回传至 2.3.7 和 2.2.12。

Argo CD 2.4 将其基本镜像从 Ubuntu 20.04 升级到了 Ubuntu 22.04，将 OpenSSH 升级到了 8.9。从 8.8 开始的 OpenSSH 放弃了对 ssh-rsa SHA-1 密钥签名算法的支持。

签名算法与生成密钥时被引用的算法是_不_相同的。没有必要更新密钥。

在建立连接时，会与 SSH 服务器协商签名算法。客户端会提供其可接受的签名算法列表，如果服务器有匹配的算法，连接就会继续。对于最新的 git Provider 上的大多数 SSH 服务器来说，除了 "ssh-rsa "之外，应该还有其他可接受的算法。

在升级到 Argo CD 2.4 之前，请检查使用 SSH 验证的 git Provider 是否支持比 rsa-ssh 更新的算法。

1.确保你的 SSH 版本大于等于 8.9（Argo CD 被引用的版本）。如果不是，请升级后再继续。 shell ssh -V ```示例输出：OpenSSH_8.9p1 Ubuntu-3, OpenSSL 3.0.2 2022年3月15日```示例输出 2.一旦有了最新版本的 OpenSSH，请按照 [OpenSSH 8.8 发布说明](https://www.openssh.com/txt/release-8.7) 中的指示操作： > 要检查服务器是否正在使用弱 ssh-rsa 公钥 > 要检查服务器是否使用弱 ssh-rsa 公钥算法进行主机身份验证，请在 > 从 ssh(1) 的允许列表中删除 ssh-rsa 算法： > >shell > ssh -oHostKeyAlgorithms=-ssh-rsa user@host > > > 如果主机密钥验证失败，且没有其他支持的主机密钥 > 如果主机密钥验证失败，且没有其他支持的主机密钥类型，则应升级该主机上的服务器软件。 > 升级。如果服务器不支持可接受的版本，则会出现类似下面的错误；```` $ ssh -oHostKeyAlgorithms=-ssh-rsa vs-ssh.visualstudio.com 无法与 20.42.134.1 端口 22 协商：未找到匹配的主机密钥类型。他们提供：ssh-rsa这表明服务器需要更新其支持的密钥签名算法，Argo CD 将无法连接该服务器。与之连接。

解决方法¶

如果无法更改服务器的密钥签名算法配置，OpenSSH 8.8 发布说明描述了一种解决方法。

> Incompatibility is more likely when connecting to older SSH > implementations that have not been upgraded or have not closely tracked > improvements in the SSH protocol. For these cases, it may be necessary > to selectively re-enable RSA/SHA1 to allow connection and/or user > authentication via the HostkeyAlgorithms and PubkeyAcceptedAlgorithms > options. For example, the following stanza in ~/.ssh/config will enable > RSA/SHA1 for host and user authentication for a single destination host: > > > Host old-host > HostkeyAlgorithms +ssh-rsa > PubkeyAcceptedAlgorithms +ssh-rsa > > > We recommend enabling RSA/SHA1 only as a stopgap measure until legacy > implementations can be upgraded or reconfigured with another key type > (such as ECDSA or Ed25519).

要将此应用于 Argo CD，可以创建一个包含所需 ssh 配置文件的 ConfigMap，然后将其挂载到 /home/argocd/.ssh/config。

配置 RBAC 以管理新的 `exec` 资源¶

2.4 引入了新的 exec RBAC 资源。

升级到 2.4 后，资源字段中包含 * 和操作字段中包含 create 或 * 的 RBAC 策略将自动授予 exec 权限。

为避免授予新特权，请用明确列出旧资源的新策略列表替换现有策略。

执行功能默认已禁用，但最好还是仔细检查一下 RBAC 配置，以执行最少的必要权限。

示例¶

旧的：

p, role:org-admin, *, create, my-proj/*, allow

新：

p, role:org-admin, clusters, create, my-proj/*, allow
p, role:org-admin, projects, create, my-proj/*, allow
p, role:org-admin, applications, create, my-proj/*, allow
p, role:org-admin, repositories, create, my-proj/*, allow
p, role:org-admin, certificates, create, my-proj/*, allow
p, role:org-admin, accounts, create, my-proj/*, allow
p, role:org-admin, gpgkeys, create, my-proj/*, allow

启用 logging RBAC 执行功能¶

2.在 2.3 中，具有 "applications, get "访问权限的用户会自动获得日志访问权限。在 2.5 中，您必须明确授予 "logs, get "访问权限。在 2.4 中，日志 RBAC 执行可以通过一个标志启用。我们建议您现在就启用该标志，以便在 2.5 中获得更轻松的升级体验。

重要的日志 RBAC 执行 将不会在 2.5 中默认启用。做出这一决定是为了避免破坏项目角色下的日志访问，因为[项目角色]不提供授予 "日志 "资源访问权限的机制。

要启用 logging RBAC 强制执行，请将此添加到 argocd-cm ConfigMap：

server.rbac.log.enforce.enable: "true"

如果想让相同的用户继续拥有 logging 访问权限，只需找到授予applications, get 访问权限的每一行，同时授予logs, get 访问权限。

示例¶

旧的：

p, role:staging-db-admins, applications, get, staging-db-admins/*, allow

p, role:test-db-admins, applications, *, staging-db-admins/*, allow

新：

p, role:staging-db-admins, applications, get, staging-db-admins/*, allow
p, role:staging-db-admins, logs, get, staging-db-admins/*, allow

p, role:test-db-admins, applications, *, staging-db-admins/*, allow
p, role:test-db-admins, logs, get, staging-db-admins/*, allow

Pod Logs UI¶

自 2.4.9 版起，只有使用显式允许获取日志策略的用户才能在用户界面中看到 pod 视图中的日志选项卡。

2.4.9 之前已知的 pod logging UI 问题¶

没有明确允许获取日志策略的用户在 pod 视图中按下 "LOGS "选项卡时，屏幕下方会收到红色的 "无法加载数据：内部错误"，并显示 "加载数据失败，请重试"。

使用新的专用服务账户测试 repo-server¶

作为一项安全增强措施，argocd-repo-server 部署使用了自己的服务帐户，而不是 default。

如果您有可能依赖 repo-server 使用 "默认 "服务账户的自定义环境（例如使用服务账户进行身份验证的插件），请务必在将 2.4 升级部署到生产环境之前进行测试。

插件¶

从任何侧载插件中移除共享卷¶

作为一项安全增强措施，sidecar 插件不再与 repo-server 共享 /tmp 目录。

如果启用了一个或多个侧卡插件，请将每个侧卡的 /tmp 卷挂载替换为使用每个插件专用的卷。

apiVersion: apps/v1
kind: Deployment
metadata:
  name: argocd-repo-server
spec:
  template:
    spec:
      containers:
      - name: your-plugin-name
        volumeMounts:
        - mountPath: /tmp
          name: your-plugin-name-tmp
      volumes:
        # Add this volume.
        - name: your-plugin-name-tmp
          emptyDir: {}

更新插件，以使用新引用的环境变量¶

如果您使用的插件依赖于用户提供的环境变量，那么必须对其进行更新，使其与 Argo CD 2.4 兼容。以下是应用程序规范的 "插件 "部分中用户提供环境变量的示例：

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    plugin:
      env:
        - name: FOO
          value: bar

今后，所有用户提供的环境变量在发送到插件的 "启动"、"生成 "或 "发现 "命令之前，都将以 "ARGOCD_ENV_"作为前缀。这样可以防止用户设置潜在的敏感环境变量。

如果您编写了处理用户 Provider 环境变量的自定义插件，请更新该插件以处理新的前缀。

如果您使用的第三方插件没有明确表示支持 Argo CD 2.4，则可能无法处理前缀环境变量。在升级到 Argo CD 2.4 之前，请向插件作者提出问题并确认支持。

确认 sidecar 插件拥有所有必要的环境变量¶

< 2.4 中的一个错误导致 init 和 generate 命令接收来自主 repo-server 容器的环境变量，优先于来自插件侧载的环境变量。

从 2.4 版开始，sidecar 插件将不会从主 repo-server 容器接收环境变量。请确保已在 sidecar 插件上设置了任何必要的环境变量，以确保 sidecar 插件能正常运行。

argocd-cm 插件将继续从主 repo-server 容器接收环境变量。