GitLab对接OAuth2实现SSO

企业内部一般都会有多个业务、应用系统,为建立统一的用户管理、身份配给和身份认证体系,实现一个账号登录所有系统,需要建立一套统一身份认证服务平台。

统一身份认证服务平台一般包含以下几个部分:

  • 账号管理:常见有AD/LDAP或者使用关系型数据库
  • 认证管理:常见有OAuth,SAML,CAS等
  • 授权管理
  • 审计监控

而单点登录(SingleSignOn,SSO),不光可以实现一个账号登录所有系统,它通过用户的一次性登录认证,就可以访问多个应用。SSO一般会被包含在认证管理功能里。

GitLab支持多种身份认证和授权方式,可以与企业的统一身份认证服务平台集成。包括对接AD/LDAP实现统一账号,对接SAML、CAS、Auth0、OAuth2等实现SSO。GitLab对于AD/LDAP、SAML、CAS、Auth0的对接提供了详细的文档。而对接Generic OAuth2的文档较粗放,网络上也没有太多参考资料,所以整理了一篇GitLab对接OAuth2的实践文章。

阅读更多

如何安全使用GitLab CICD SSH部署

1. 背景

使用GitLab CICD,在部署方面,主要有两种方式:

  • 部署到K8S集群

    • Push模式:流水线通过kubectl执行命令部署,这需要把K8S的权限给流水线,存在安全风险

    • Pull模式:使用GitLab Agent for Kubernetes或ArgoCD,通过GitOps的方式“监听”GitLab的变化,触发部署

  • 部署到服务器

    目前仍有不少企业因为行业性质或者场景所限,没有使用K8S等云原生技术,还在采用传统的服务器方式进行部署。一般使用sshscprsync等命令部署到服务器。GitLab也提供了基于SSH keys的部署。详见:Using SSH keys with GitLab CI/CD | GitLab

    需要说明的是,如果是使用专用的编译机进行编译构建,然后部署到指定的服务器,只需要实现编译机和部署服务器的免密SSH登陆即可,相对简单。但如果使用容器进行编译构建,然后部署到服务器,就需要按照上面文档中提到的,配合GitLab CI/CD环境变量,将SSH_PRIVATE_KEY等变量存储到GitLab Project、Group或Instance中,实现复用。且可以通过GitLab CI/CD环境变量的Mask设置,掩藏这些变量在CICD日志中的显示。详见:GitLab CI/CD variables | GitLab

    但遗憾的是Mask功能目前是有限制的,对于SSH_PRIVATE_KEY这种多行的变量无法直接使用Mask功能。这样开发人员就可以在.gitlab-cti.yml文件的脚本中执行echo $SSH_PRIVATE_KEY,在流水线的日志中输出SSH Keys,存在密钥泄露风险。

    The value of the variable must:

    • Be a single line.
    • Be 8 characters or longer, consisting only of:
    • Not match the name of an existing predefined or custom CI/CD variable.

这个问题在GitLab的Issue上挂了有一年多 ,看样子短时间没法解决。有没有其他方式Mask SSH_PRIVATE_KEY?于是开始了各种折腾。

2. 方案

阅读更多

一段祖传代码引起的血案

WARNING:本文含有强烈的刺激性气味,请勿在进食期间阅读。如感到血压上升、眩晕、呼吸急促,请立即停止阅读。

1. 初识祖传代码

祖传代码(Legacy Code),就字面意思而言,就是无数的前任程序猿留给你的最后遗产。这些代码几乎没有可维护性,缺少注释、命名不规范、依赖错综复杂,你根本读不懂它,但神奇的是它们都能跑起来。不要试图修改它们,因为要么就无从下手,要么一改就出大问题。每家公司都会有那么些“历史遗留问题”。亚马逊的工程师亲切的形容他们的祖传代码为“屎山”:“每次你想修正一个bug,你的工作就是爬到屎山的正中心去”。

一家企业里,偶尔一两座屎山无伤大雅,毕竟每家企业都有很长的故事。但如果“你看那一座座山,一座座山川,一座座山川相连”,这种情况就很危险了。山路十八弯,难以持续的为企业快速增长提供高效支撑。企业发展的越快,屎山的债务积累就越多,形成恶性循环,最终企业员工只能望山兴叹,下山逃难去了。如何解决屎山问题?如何形成一个正向的发展循环?如何打造一个研发流程的最佳实践?如何加强质量内建?那我们就要先爬到屎山的正中心去一探究竟,明知山有屎,偏向屎山行。

阅读更多

阿里云云效2020踩坑指南

自2019年加入一家传统生物医疗器械公司以来,我们组建了一支40余人的团队主攻企业数字化转型,做新产品和新业务模式探索。一年多的时间,我们也搭建了一整套基于阿里云的微服务架构的平台体系,包括K8S服务编排、监控预警日志、基于Gitlab和Jenkins的CI/CD等等。此外还使用过Leangoo、Jira、Confluence、企业微信在线文档、NextCloud等协同工具,最后稳定在Jira+Confluence+Nextcloud组合。但由于各个系统不方便打通伴随人员增加,管理压力和安全隐患等问题逐渐暴露出来,所以近期就在考虑用全家桶方案整合各个系统。

我们先后也看了不少方案,像Worktile、Teambition、Jira等。早在18年,我也看过阿里云云效平台,那时候的版本功能和UI还比较简陋,尤其是项目协同这块“很不好用”。而Jira太重,不符合国内用户的使用习惯。最后还是在今年的云栖大会上,重新认识了Teambition。新的UI设计、流水线的引入、知识库WIKI的整合等等,至知识库还支持Markdown、Roadmap、思维导图,而且是在线协同。本来已经选定Teambition了,无意间又在阿里云云效看到新出了云效的2020版,简单浏览过,发现就是Teambition的整合版,与阿里云做了打通,加入了代码仓和成品仓(正因为如此,云效2020的费用比Teambition企业版要贵近200/人年)。此外,还推出了云鹰计划,99人的团队只需1万多就可以用一年。所以我们决定通过云鹰计划试水,毕竟跟我们正在用的阿里云有很好的结合。

任何迁移,任何第一个吃螃蟹的都要付出代价。虽然阿里云效2020确实提供了一些很好用的功能,帮我们解决了一些问题,但还是存在一些“缺陷”,或者是我们使用方法不对又或者是使用习惯问题。我们把这些坑暴露出来,也是希望给到“后人”一些参考,也希望能给到阿里云一些有价值的建议。

1. 项目协作 Projects

  • 任务类型切换不方便

    任务类型的切换要下拉选择,用户需要两步操作,感觉繁琐。而Jira则是需求和任务显示在一个维度里。个人感觉Tag或者Tap的切换操作更好。

  • 添加任务时不能直接添加子任务

    要等主任务添加完成才可以点击添加子任务,不是很方便。

  • 给任务添加工时字段

    任务模板默认没有“工时”字段,而在Scrum中通常需要这个字段作为评估工作量的指标。云效2020(Teambition)是支持自定义任务字段的,进入某个项目,在右上角的“菜单” - 项目设置 - 任务设置 - 任务类型设置 - 选择具体的类别 - 进入字段设置 - 增加“工时”字段。也可以在系统设置中设置,全局项目生效。

阅读更多