security

starlightBlog.tags.count

ArgoCD 密码重置：如何恢复遗忘的 admin 登录凭证

starlightBlog.post.date

故障背景

在日常运维中，如果遗忘了 ArgoCD Web 面板中 admin 账户的自定义登录密码，将导致无法通过图形界面管理应用。

ArgoCD 将 admin 账户的密码哈希值存储在名为 argocd-secret 的 Kubernetes Secret 资源中。当我们在 UI 界面修改密码时，系统实际上是在更新该 Secret 内部的 admin.password 字段。如果该字段被清空或移除，ArgoCD 将自动回退，允许使用系统在初始化时生成的默认密码进行登录。

基于这一底层逻辑，我们可以通过命令行强制重置密码状态。

密码恢复流程

请确保你的终端已连接到目标 K3s 集群，且具备操作 argocd 命名空间的高级权限。

步骤 1：移除自定义密码字段

使用 kubectl patch 命令，强行从存储配置的 Secret 中剔除自定义密码记录。这相当于清除了系统中后续添加的身份验证覆写规则。

kubectl patch secret argocd-secret -n argocd --type=json -p='[{"op": "remove", "path": "/data/admin.password"}]'

执行成功后，终端应返回 secret/argocd-secret patched。

步骤 2：重启 API Server 服务

密码字段移除后，需要重启 ArgoCD 的前端 Server 组件，使其强制重新读取底层的 Secret 状态。

kubectl rollout restart deploy argocd-server -n argocd

等待几秒钟，确保新的 Pod 成功启动并接管流量。

步骤 3：提取系统初始密码

此时，ArgoCD 已经回退到出厂安全状态。我们需要从专门存储初始密码的 Secret (argocd-initial-admin-secret) 中提取密码的 Base64 原文并进行解码。

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo

请复制终端输出的这串随机字符串，这是你目前的唯一登录凭证。

步骤 4：登录并设置新密码

浏览器访问你的 ArgoCD 面板。
账号输入 admin，密码粘贴刚刚提取的初始字符串。
登录成功后，导航至页面左侧的 User Info 选项卡。
点击 Update Password，输入当前密码（初始密码）并设定一个新的、已妥善记录的自定义密码。

拆除赛博防盗门：如何安全卸载 Sealed Secrets

starlightBlog.post.date

🏗️ 拆迁前的致命警告 (The OwnerReference Trap)

在动用挖掘机之前，包工头必须先弄清楚 Kubernetes 底层极其冷酷的垃圾回收逻辑：属主引用 (OwnerReferences)。

当我们使用 Sealed Secrets 时，Controller 会读取我们提交的乱码 (SealedSecret 资源)，并在同命名空间下生成一个真实的密码 (Secret 资源)。在这个过程中，Controller 会给真实的 Secret 打上一个烙印：“你的主人是那个 SealedSecret”。

致命后果：如果你直接卸载 Sealed Secrets 并删除了它的 CRD（自定义资源定义），集群里所有的 SealedSecret 会瞬间消失。K8s 垃圾回收器一看“主人死了”，就会把底层真实的 Secret 全部一起拉去陪葬。你的数据库、网盘、可视化面板会在下一次重启时，因为找不到密码而全部崩溃瘫痪！

🔐 第一阶段：跑路前的保命操作 (备份主密钥)

无论你是想重装集群，还是想迁移到其他加密方案（如 SOPS 或 External Secrets），备份主密钥都是重中之重。丢失了这把私钥，你存在 GitHub 上的所有加密乱码将永远变成解不开的死数据。

打开终端，从系统核心区 (kube-system) 提取你的主密钥并保存到本地安全的地方：

# 提取带有特定标签的主密钥 Secret，并导出为 YAML
kubectl get secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key -o yaml > sealed-secrets-master-key-backup.yaml

✂️ 第二阶段：无损剥离与拆除 (Safe Teardown)

如果你希望在卸载 Sealed Secrets 之后，集群里的应用依然能拿着现有的明文密码继续运行（无损拆除），你需要遵循以下步骤。

步骤 1：解除密码的“主仆契约”

我们需要切断真实 Secret 与 SealedSecret 之间的属主绑定。这可以通过批量 Patch 抹除 ownerReferences 来实现（需要宿主机安装 jq 工具）。

执行以下硬核除名脚本（遍历所有命名空间）：

# 找出所有由 SealedSecret 生成的真实 Secret，并切断它们的从属关系
kubectl get secrets --all-namespaces -o json | jq '.items[] | select(.metadata.ownerReferences != null) | select(.metadata.ownerReferences[].kind == "SealedSecret") | .metadata.namespace + " " + .metadata.name' | tr -d '"' | while read -r ns name; do
  echo "正在解放密码: $ns / $name"
  kubectl patch secret $name -n $ns --type=json -p='[{"op": "remove", "path": "/metadata/ownerReferences"}]'
done

执行完毕后，所有的业务密码都变成了自由的 K8s 原生对象，不再受 Sealed Secrets 牵连。

步骤 2：纯手工物理强拆解密守卫

既然密码已经自由，且我们准备对集群进行彻底重置，我们就不再依赖任何自动化工具，直接使用 K8s 原生命令进行“物理强拆”。

我们需要把部署在核心区 (kube-system) 的 Controller、Service 以及配套的 RBAC 权限全部清理干净。为了精准打击且不误伤其他核心组件，我们利用标签 (Label) 进行批量扫荡：

# 1. 拆除运行中的核心建筑（Pod、Service、Deployment 等）
kubectl delete all -l app.kubernetes.io/name=sealed-secrets -n kube-system

# 2. 清扫遗留的系统权限（Role、ClusterRole 等），不留任何幽灵后门
kubectl delete clusterrole,clusterrolebinding -l app.kubernetes.io/name=sealed-secrets 2>/dev/null
kubectl delete role,rolebinding -l app.kubernetes.io/name=sealed-secrets -n kube-system 2>/dev/null

(💡 监理提示：如果你当初是直接使用原生的 helm install 命令安装的，这里也可以更优雅地使用 helm uninstall sealed-secrets -n kube-system 一键卸载。但使用上述的标签扫荡法作为兜底，是最为彻底的。)

步骤 3：深度清理地基与残骸

为了保证赛博堡垒的绝对干净，我们需要把底层的 CRD 协议和留存的主密钥彻底铲平。

1. 销毁加密协议图纸 (CRD)：

# 这会删除集群中所有的 SealedSecret 乱码对象，但因为我们在步骤 1 解除了绑定，真实 Secret 不会受影响
kubectl delete crd sealedsecrets.bitnami.com

2. 销毁集群中的主密钥： 虽然 Controller 死了，但主密钥可能还静静地躺在 kube-system 里。

kubectl delete secret -n kube-system -l sealedsecrets.bitnami.com/sealed-secrets-key

🎉 验收与后续规划

巡查集群状态：

kubectl get pods -n kube-system | grep sealed

如果没有任何输出，恭喜你！这扇“赛博防盗门”已经被你完美拆除，而且大楼里的所有业务都在照常营业。