没有SSO就不要谈Infra

单点登陆（Single Sign on）现在已经很普遍了，比如Google，一次登录之后可以直接访问Gmail、Calendar、Docs、Youtube、Keep等所有产品。在互联网公司内网，SSO应该都是必备设施，一次登录后可以访问ERP、Wiki、Ticket、代码、服务器资源等所有系统。如果你们公司没有——我觉得你需要跳槽来培养一些品味。

以上我们都还说的是比较成熟的Web SSO，但是我非常惊奇的是，很多一线大公司竟然都还没有实现命令行下的SSO以及依赖于此的资源访问控制（access control）。在这里你经常会遇到什么事情呢——

有一些Linux服务器，它们的维护方式是SSH上去做操作，用户名、密码是靠少数几个人保管着，严谨的人靠脑子记、靠口口相传，不严谨的人写在便签纸上贴在电脑上、写在wiki里、毫不在意地发在100人的微信群里——随处可见的明文密码。

有一些没有ACL的存储里保存着各种孤本数据，谁都可读可写。有一天猪队友手一抖全给删了，如果不是他自觉承认，其实根本查不出是哪头猪。

聪明的人出现了，他们又做了一套独立于公司体系之外的权限管理系统，强大无比，升职加薪。

但你觉得这套“自主研发”的权限系统其实很蠢，而公司里竟然有很多套类似的系统，你自己就有很多个用户名、密码，用以访问不同的资源。

所以每当有人说要做一个权限管理系统，我都想问：这是用户的需求还是升职的需求？是升职完就废弃或者甩锅给别人、还是承诺维护五年以上？我们工程师圈子始终有一个怪现象，那些善于不停挖坑弃坑的人，只需要0.2的effort就拿走0.8的credit；后面的人再兢兢业业、干到死也就是0.2的credit。我钦佩前者创新和讲故事的能力，但其中只有少数是出自对未来技术走向的洞察，多数是重复造轮子、面向升职编程。

说得有点远了，回到我们的话题。如何设计一个统一的Terminal SSO呢？其实也并不复杂，跟Web SSO是一样的：

第一步是身份验证，获得员工在公司的唯一标识，一般就是邮箱前缀吧。

第二步是访问控制，所有工具链都应该比对身份与权限，得出结论“用户A以身份X执行了操作”，并且写入log。

身份验证有比较成熟的方案，例如RSA。可以参考常见的Git仓库权限管理，用户登录Web SSO，上传一份本机的公钥。

访问控制其实就是简单的树状用户组。例如一个学校的校友会组织形式：

小王属于“三年二班”用户组，“三年二班”属于“三年”用户组，“三年”属于“A校”用户组。

小王以“小王”的身份访问了自己的成绩档案；

小王以“三年二班”的身份访问了三年二班班聚照片；

小王以“三年”的身份访问了三年校友通讯录；

小王收到了A校校友办公室发给“A校”的校庆通知。

我们一般也会在每一层都有一些具有更高管理权限的组别，比如：

小刘属于“三年二班班委”，可以加人、踢人等；

同时小刘作为班长，属于“三年管委会”，可以跟其他班长一起在年级级别发一些公告等；

同时小刘还德高望重，被选为“A校校友会理事”，可以在更高级别做出一些操作。

总之每一个操作，都是“A以B的身份做出操作C”，我们只对A进行身份验证，并鉴定他是否可以具有B的身份。而不是A记住了一堆密码，以B的身份登录进系统去做操作，因为这样我们只能记录到“B做出操作C”，而且B的密码很容易泄漏到更广范围。

行之有年的“公共邮箱”，就是这样一个脆弱的“私密”环境。

行之有年的上百人的“X校校友微信群”，就是这样一个经常混入神秘陌生人但又无法甄别的“可信”朋友圈。

而如果一个代表科技巅峰的无人车大公司内部研发环境也是如此，我很难相信他们的Infra可以支撑起100台车的管理。