别再各认各的爹了：用 openEuler 构建一个真正“分布式”的身份认证系统

大家好，我是 Echo_Wish。
这几年在 openEuler 生态里折腾得越久，我越发现一个特别现实、也特别容易被忽略的问题：

系统越做越分布式，身份认证却还停留在“单机思维”。

你肯定见过这种场景👇

• 一堆微服务
• 一堆节点
• 一堆账号体系
• SSH、API、Web、运维平台……各认各的身份

最后的结果就是：
人是同一个人，系统却不认你是“同一个你”。

今天这篇文章，我想站在一个运维 + 系统工程的视角，聊聊一件“不性感但极其重要”的事：
👉 如何基于 openEuler，构建一个靠谱、可扩展的分布式身份认证系统。

不讲玄学，不搞“企业级 PPT”，咱就按真实工程来。

一、引子：为什么“身份”成了分布式系统的隐形炸弹？

很多团队一开始的系统演进路径都差不多：

1. 一台服务器
2. 几台服务器
3. 微服务
4. 多集群
5. 多地域

系统规模翻了 10 倍，
身份认证方案却还停留在：

• /etc/passwd
• 本地用户
• 各服务自己校验账号密码

你可能会觉得：“现在也能跑啊？”

但现实是：

• 用户离职，账号删不干净
• 权限收不回来
• 日志里全是 unknown user
• 出事故根本追不清责任

说句不好听的：
系统不是被黑的，是被“身份混乱”拖死的。

二、先立个核心观点：分布式系统里，身份必须“集中定义，分布使用”

这是我这些年踩坑后总结的一句话：

身份不集中，安全一定碎；
权限不统一，审计一定废。

但注意——
集中 ≠ 单点。

我们追求的是：

• 身份数据集中管理
• 认证能力分布式使用
• 节点之间彼此信任但可校验

而 openEuler，恰好非常适合做这件事。

三、openEuler 能给我们什么“底座能力”？

先别急着上复杂架构，我们得先搞清楚 openEuler 手里有什么牌。

1️⃣ 原生支持企业级身份组件

在 openEuler 上，你可以非常自然地用到：

• LDAP / FreeIPA
• Kerberos
• PAM
• SSSD
• TLS / OpenSSL

而且这些都不是“凑合能用”，
而是生产级别的组合拳。

2️⃣ 系统层面就支持“集中认证”

openEuler 的理念很明确：

不要让每个应用自己“发明身份系统”。

所以它非常强调：

• 系统级身份
• 统一认证入口
• 标准接口（PAM / NSS）

四、整体架构：我们要搭一个什么样的系统？

先给你一个不复杂、但很实用的目标架构👇

           +------------------+
           |  Identity Center |
           | (LDAP / Kerberos)|
           +------------------+
                    |
        --------------------------------
        |              |              |
   openEuler Node  openEuler Node  openEuler Node
   (SSSD + PAM)    (SSSD + PAM)    (SSSD + PAM)
        |              |              |
     SSH / API      Service A      Service B

核心思想就一句话：

身份在“中心”，认证在“节点”。

五、实战第一步：在 openEuler 上搭建统一身份源（LDAP）

我们先从最基础、也是最稳妥的一步开始。

1️⃣ 安装 LDAP 服务（示例）

dnf install -y openldap openldap-servers openldap-clients

初始化数据库、配置 base DN，这里不展开细节，重点是理念。

你的 LDAP 里，应该至少有：

• 用户（People）
• 用户组（Groups）
• 角色或权限标签（可选）

2️⃣ 一个“统一身份”的核心价值

当用户只存在于 LDAP 中时：

• 创建账号 = 创建一条目录记录
• 删除账号 = 删除一条记录
• 权限变更 = 修改属性

不需要上每台服务器敲 userdel。

六、第二步：openEuler 节点如何“认”这个身份？

这里就是 openEuler 非常好用的一点了。

1️⃣ 使用 SSSD 作为认证代理

dnf install -y sssd sssd-ldap oddjob-mkhomedir

SSSD 的作用，可以简单理解为：

帮 openEuler 把“外部身份”翻译成“本地可用”。

2️⃣ 一个极简的 SSSD 配置示例

[sssd]
services = nss, pam
domains = LDAP

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_uri = ldap://ldap.example.com
ldap_search_base = dc=example,dc=com

配置完成后，你会发现一件很神奇的事：

id echo_wish

👉 本地根本没有这个用户，
👉 系统却“认识他”。

这就是分布式身份的感觉。

七、第三步：把认证能力“用”到更多场景里

很多人到这一步就停了，只用来 SSH 登录。
说实话，有点可惜。

场景一：统一运维登录

• 所有 openEuler 节点
• 同一套账号
• 同一套密码策略

离职员工？
👉 LDAP 禁用即可，全网失效。

场景二：服务进程身份化

你完全可以：

• 给服务分配“服务账号”
• 通过 Kerberos / Keytab 认证
• 服务与服务之间不用明文密钥

kinit -k -t service.keytab service_a@EXAMPLE.COM

服务，也应该有身份。

场景三：审计和追责终于靠谱了

当：

• 系统登录
• 服务调用
• 管理操作

都基于统一身份时，你会发现：

日志突然“会说人话”了。

八、再说点现实问题：这套方案值不值得？

我说句实在话：
一开始确实麻烦。

• 组件多
• 概念多
• 配置容易踩坑

但一旦跑顺，你会明显感觉到：

• 账号不再失控
• 权限不再混乱
• 安全边界更清晰

对运维来说，这是一种长期解脱。

九、Echo_Wish 式思考：身份系统，其实是“组织结构”的技术映射

最后说点偏观点的。

我越来越觉得：

身份认证系统，反映的是你对“人、系统、权力”的理解。

• 本地账号泛滥 → 管理随意
• 权限模糊 → 责任模糊
• 审计缺失 → 风险靠运气

而 openEuler + 分布式身份这套方案，本质上是在帮你做一件事：

把“组织秩序”，写进系统底层。

这不是为了“更安全”，
而是为了——系统能长期健康运转。

写在最后

如果你现在正处在：

• 节点越来越多
• 系统越来越复杂
• 安全和审计越来越痛苦

那我真心建议你认真看看：
👉 分布式身份认证这件事，早点做，早解脱。