V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
ltltfuture
V2EX  ›  程序员

公共 Git 代码库如何管理敏感信息?

  •  
  •   ltltfuture · 2023-08-15 06:02:27 +08:00 via Android · 2604 次点击
    这是一个创建于 470 天前的主题,其中的信息可能已经有所发展或是发生改变。

    请问各位在公共代码库里如何管理敏感信息 比如用户名,密码,token 等等

    不知道现在企业实际在用的方法是什么

    我搜到的一些方式:

    一个公共 repo (存代码),一个私有 repo(放敏感信息),公共 repo 用 submodule 调用私有 repo

    或者写一个示例的密码文件比如*.json repo clone 之后替换掉

    37 条回复    2023-08-16 20:38:21 +08:00
    charlie21
        1
    charlie21  
       2023-08-15 06:56:11 +08:00 via Android
    cp .example.env .env
    nano .env
    way2explore2
        2
    way2explore2  
       2023-08-15 07:00:29 +08:00
    仓库不应该包含任何敏感信息


    .env.example


    或者用 AWS Secret Manager 这类服务
    ltltfuture
        3
    ltltfuture  
    OP
       2023-08-15 07:01:33 +08:00
    @charlie21 请问一下这个.env 涉及到多人合作如何管理呢?比如存在私有 sftp ?或者放内部 wiki 上?
    ltltfuture
        4
    ltltfuture  
    OP
       2023-08-15 07:02:15 +08:00
    @way2explore2 也就是说私有仓库也不安全对吗?
    Chad0000
        5
    Chad0000  
       2023-08-15 07:04:59 +08:00
    这种东西放 Pipeline 里,设置加密,只有发布的时候会写进去,就变成只写不能读了。
    ltltfuture
        6
    ltltfuture  
    OP
       2023-08-15 07:12:29 +08:00
    @Chad0000 这里的 pipeline 是指 CI/CD 里面的吗?
    lin07hui
        7
    lin07hui  
       2023-08-15 07:18:29 +08:00
    https://docs.gitlab.com/ee/user/application_security/
    Security/Secret-Detection.gitlab-ci.yml
    其它平台也有类型的 ci
    ltltfuture
        8
    ltltfuture  
    OP
       2023-08-15 07:21:39 +08:00
    @lin07hui 感谢,我学习一下
    Rocketer
        9
    Rocketer  
       2023-08-15 07:22:22 +08:00 via iPhone
    简单弄的话就是在服务器上设置环境变量,这样密码等信息只存在于服务器内存中。

    正规做法可以用各云计算平台的密码管理,比如 AWS Secrets Manager
    Chad0000
        10
    Chad0000  
       2023-08-15 07:28:28 +08:00
    @ltltfuture
    对的,源码里你使用关键字,然后在 CI/CD 里读取敏感内容并替换。每个平台会有不同的说法,比如 Azure DevOps 叫 Variables ,Github 叫 Secrets 。这些都是可以在 CI/CD 中读取写入文件的。
    ltltfuture
        11
    ltltfuture  
    OP
       2023-08-15 07:30:37 +08:00
    @Rocketer 感谢,也就是说对环境变量这个选项的话的,也是比如靠管 infrastructure 的人来管理更新,其他人写码运行即可对吗
    ltltfuture
        12
    ltltfuture  
    OP
       2023-08-15 07:31:44 +08:00
    @Chad0000 感谢解释
    charlie21
        13
    charlie21  
       2023-08-15 07:41:36 +08:00 via Android   ❤️ 1
    大概思路是:首先 把敏感信息拿到项目 repo 之外,其次预计到 build 阶段会读取敏感信息(否则将会 build 失败),最后安排各自环境可以读取到敏感信息 帮助各自环境下 build 成功。

    对于一个敏感信息(例如买的某个库的序列号,比如 fontawesome 的序列号:如果没有这个序列号则 npm install 时候安装此包时候会失败),在开发环境里 写入本机 ~/.npmrc 或其它位置 以确保本机 npm install 安装成功 然后就可以开始本地开发了;在服务器环境如果没用 docker 则也可以直接写在如上文件位置呢 如果用 docker 则写在构建 docker container 环境配置里 便于读取如上文件位置 最终确保服务器端或 docker container 环境能读取到文件,此 container 里的一个项目最终可 build 成功

    至于需要公共编辑敏感信息的情况,最好是乐意参与公共编辑的相关人们找个下午的时间输出一个最终配置办法(能跑通生产环境和开发环境)。然后这个版本就不要再动了,否则出事了咋整呢?最后指定一个最高权限的人 / 由一个最高权限的人(按需)分发给线上服务器环境 or 需要配置开发环境的人,并且记录线上配置过程(方便出错时候排错) or 写一个文档教人怎么配置开发环境。同时剥夺其他人的配置修改权,因为多人乱改呢出错时候很难排错。
    ltltfuture
        14
    ltltfuture  
    OP
       2023-08-15 07:54:19 +08:00
    @charlie21 感谢详细的回答
    8355
        15
    8355  
       2023-08-15 09:26:45 +08:00
    你说的公共代码库是指啥,公司内部的公共项目?还是 github 的开源?
    lingeo
        16
    lingeo  
       2023-08-15 09:29:46 +08:00
    很多 API 文档都是推荐你将各种认证加到你的运行环境中,不要写在代码里,执行的时候通过环境变量调用。
    ltltfuture
        17
    ltltfuture  
    OP
       2023-08-15 09:34:04 +08:00 via Android
    @8355 感谢,我看 github gitlab 这些都有环境变量设置
    ltltfuture
        18
    ltltfuture  
    OP
       2023-08-15 09:36:43 +08:00 via Android
    @8355 都算吧,隐私信息毕竟是要授权的人才能用的,所以其实就是问怎么样的形式储存然后让有权限的人能改没权限的人不影响使用程序
    guanzhangzhang
        19
    guanzhangzhang  
       2023-08-15 10:06:31 +08:00
    敏感信息支持配置文件或者环境变量。
    然后这个文件默认读取相对路径下 xxx.env 或者 xxx.config ,放一个 example.env example.config ,gitignore 里加上 xxx.env 和 xxx.config
    ci 里例如 action 之类的设置 run 的 env
    ltltfuture
        20
    ltltfuture  
    OP
       2023-08-15 10:23:02 +08:00 via Android
    xudaxian520bsz
        21
    xudaxian520bsz  
       2023-08-15 11:59:17 +08:00
    k8s 的 configmap 中
    tabris17
        22
    tabris17  
       2023-08-15 12:16:47 +08:00
    私有信息都是写在环境变量里的,为何你要将数据落地?
    Alias4ck
        23
    Alias4ck  
       2023-08-15 12:27:33 +08:00
    我记得 有类似的 security 项目
    https://github.com/awslabs/git-secrets
    Alias4ck
        24
    Alias4ck  
       2023-08-15 12:29:57 +08:00
    之前瞟过一样,才发现是 aws 的哈哈😄😄
    ltltfuture
        25
    ltltfuture  
    OP
       2023-08-15 12:33:41 +08:00 via Android
    @Alias4ck 这个好像适用于私有 repo ,放共有 repo 有安全隐患
    ltltfuture
        26
    ltltfuture  
    OP
       2023-08-15 12:34:00 +08:00 via Android
    ltltfuture
        27
    ltltfuture  
    OP
       2023-08-15 12:36:34 +08:00 via Android
    @tabris17 比如我写 pyspark data pipeline 有很多不同的 data source 最后可能需要打包提交到 emr 集群上计算
    libook
        28
    libook  
       2023-08-15 12:39:19 +08:00
    我去年做了一个项目,在全公司设立制度禁止在代码中包含敏感信息。提供了多种整改方案,比如用 k8s 的 Secret 、环境变量、数据库或 K-V 存储来保存敏感信息,开发人员禁止接触敏感信息,仅获得授权的运维人员或负责的业务人员可以接触到。

    现有的、已经在代码中包含敏感信息的情况,要全部更换敏感信息,比如重设密码、重新生成 token 和证书。

    开发、预发布、线上环境采用不同的认证凭证。
    tabris17
        29
    tabris17  
       2023-08-15 12:49:59 +08:00
    @ltltfuture 你需要一个分布式配置中心
    ltltfuture
        30
    ltltfuture  
    OP
       2023-08-15 12:53:13 +08:00 via Android
    @libook 感谢分享实战的经验,想请请教一下,
    现在比如说有个 repo 里面有整个公司 data pipeline, 主要写 pyspark ,会用到 ci/cd 比如说 做一些 transformation 的 unit test 在里面 unit test 可能就用一些小的 sample data 验证,这个一个 docker 应该可以搞定,之后在 dev 环境中做 end to end test 这必然会涉及到很多 credentials 比如各种数据库的 connection string, API token, ftp username password 这些 pipeline 在 emr 上跑,我能想到的一个是我会使用 airflow 可以使用 airflow 的 connection 来保存, 但如果我要打包.py 成 zip submit 到 emr 集群有没有什么比较好的管理敏感信息的方法呢
    ltltfuture
        31
    ltltfuture  
    OP
       2023-08-15 12:53:54 +08:00 via Android
    @tabris17 这个有哪些现成的工具 能推荐一下吗
    tabris17
        32
    tabris17  
       2023-08-15 13:00:28 +08:00
    @ltltfuture 新手推荐用 Consul ,几乎不用配置,每个平台都有发布二进制包,拉下来就跑。接口是 HTTP 的。自带 WEB 管理 UI
    ltltfuture
        33
    ltltfuture  
    OP
       2023-08-15 13:01:24 +08:00 via Android
    @tabris17 感谢 我去了解一下
    libook
        34
    libook  
       2023-08-16 10:20:38 +08:00
    @ltltfuture #30 大数据基础设施虽然我们也有,但我并不是很了解实际内部工作流,我只是把原始需求提给了大数据架构师。

    我尝试理解一下你描述的场景。
    首先不同的环境要用不同的 credentials ,dev 肯定和正式环境的不一样,这样即便 dev 的泄漏了,也不影响正式环境。
    其次我不清楚你们的 dev 环境是不是由运维或专人全权维护的,如果是的话那么就和线上正式环境一样,仅专门人员可以访问和操作运维环境,使用外挂的方式管理和向服务注入敏感信息。只要运维环境的访问权限限制死,用 CI/CD 来实现手工注入敏感信息也是可以的。

    这需要你们有一个相对健全的 DevOps 流程,如果开发兼 dev 环境的运维,肯定就没法把敏感信息分出来了。
    xudaxian520bsz
        35
    xudaxian520bsz  
       2023-08-16 13:03:05 +08:00
    HashiCorp Vault 这个方案也是好的,支持部署到 k8s 中,并且 SpringBoot 也提供了对它的支持。
    ltltfuture
        36
    ltltfuture  
    OP
       2023-08-16 20:37:39 +08:00
    @libook 嗯,谢谢解答,我们这属于小团队,得开发运维一起抓,所以这方面还是有很多不熟悉的
    ltltfuture
        37
    ltltfuture  
    OP
       2023-08-16 20:38:21 +08:00
    @xudaxian520bsz 这个看起来不错,刚去看了看官网的介绍视频,还得研究一下能不能用到自己的环境
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   3270 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 44ms · UTC 12:25 · PVG 20:25 · LAX 04:25 · JFK 07:25
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.