browserstack/enigma

# Enigma 访问管理  [](https://github.com/browserstack/enigma/actions/workflows/unit-tests.yml) [](https://github.com/browserstack/enigma/actions/workflows/semgrep.yml) 通过单一门户管理工具的访问权限。 ## 什么是 Enigma？ Enigma 是一个基于 Web 的内部访问管理工具，它可以： * 帮助员工获取各种内部和第三方系统及组件的访问权限，例如 git 仓库、云机器（通过 ssh）和仪表盘。 * 辅助记账管理。 * 协助满足合规性要求。 * 在一处管理所有工具的资产清单。 该工具由 2 个不同的组件组成：一个中央 Web 服务器和可插拔的访问模块。 本代码仓库是中央 Web 服务器的代码库。 有关此工具已发布的访问模块，请参阅[这里](https://github.com/browserstack/enigma-access-modules)。 有关如何创建自定义访问模块，请参阅[此文档](/docs/%E2%80%9CHow-to%E2%80%9D%20guides/Adding%20Modules.md) ### 解决的问题 Enigma 访问管理工具是 BrowserStack 内部开发的，旨在解决我们在员工访问管理方面观察到的一些问题： * 没有供个人查看其跨工具访问权限的统一门户 * 没有供跨供应商管理员工访问权限的统一门户 * 缺少针对员工跨工具授予和撤销访问权限的集中审计跟踪记录 * DevOps 团队和工具负责人在处理访问权限授予和撤销请求时存在重复的运维工作 * 缺少符合 SOC2 和 GDPR 标准的标准化方法来管理外部工具的个人和管理员访问权限 * 缺少简单的整合流水线来触发离职员工流程，以撤销该员工对所有工具的访问权限 * 个人无法在每个工具中维护独立的身份 * 个人可能在一个工具中拥有多个账户，某些工具可能存在多个组织范围内的域名 * 无法在组织-团队层级结构之外请求、审计和跟踪员工的访问权限。需要提供对临时团队/组的支持。 * 员工可能会在不同的团队间调动，有时临时项目需要某些访问权限，而这些权限并不是整个团队都需要的 * 无法列出一系列要授予给参与某项目的员工的访问权限 * 如果将某个人添加到项目中，应能通过单击操作，为所有相关工具发起访问请求（基于参与该项目的其他人员构建的知识库） ## 用法 以下步骤用于从已发布的 Docker 容器镜像在本地托管 Enigma。 关于开发环境设置，请遵循以下文档： [使用 Docker 设置](/docs/“How-to”%20guides/User%20Guides/Local%20Developer%20Setup/Local%20Setup%20with%20Docker.md)， [不使用 Docker 设置](/docs/“How-to”%20guides/User%20Guides/Local%20Developer%20Setup/Local%20Setup%20without%20Docker.md) #### 前置条件 您需要在本地运行 docker 守护进程才能运行已发布的容器。 如果您尚未设置 docker，请遵循[这里](https://docs.docker.com/get-docker/)的指南。 #### 步骤 1. 确保本地存在有效的 `config.json`。 默认的 [config.json.sample](https://github.com/browserstack/enigma/blob/main/config.json.sample) 应足以启动。 然后，您可以为要与 Enigma 集成的模块添加特定配置。 有关配置的详细说明，请参阅[此文档](/docs/Configuration%20Guide.md) 2. 通过将下载的配置挂载到容器来运行 Enigma docker 容器 ``` docker run --rm --name enigma -p 8000:8000 -v "$(pwd)/config.json":/srv/code/dev/config.json browserstack/enigma:v1 ``` 确保端口 8000 可用，并确保 config.json 的路径正确。 完成！Enigma 应该已在本地端口 8000 上运行 关于首次用户登录，请参阅[此文档](/docs/%E2%80%9CHow-to%E2%80%9D%20guides/User%20Guides/First%20User%20Setup.md) ## 贡献此工具 - 该代码库已针对 Python 3.11.0 进行了测试 - 设置开发环境的 pre-commit hooks（参见[下方](#rules-enforced-by-the-pre-commit-hooks)的规则） - 运行：`npm install @commitlint/cli @commitlint/config-conventional` - 运行：`pip install pre-commit==3.8.0` - 在本项目的基础目录下运行：`pre-commit install --install-hooks --overwrite` - 运行：`pre-commit autoupdate` - 运行：`pre-commit run --all-files --show-diff-on-failure --color always` #### Commit Message 指南 格式：`(): ` `` 是可选的 `Type` 可以是以下类型之一： - `feat`：面向用户的新功能，而非构建脚本的新功能 - `fix`：面向用户的错误修复，而非构建脚本的修复 - `docs`：对文档的更改 - `style`：格式化、缺少分号等；无生产代码更改 - `refactor`：重构生产代码，例如重命名变量 - `test`：添加缺失的测试、重构测试；无生产代码更改 - `chore`：更新 grunt 任务等；无生产代码更改 - `bump`：增加某些内容的版本，例如依赖项 - `build`：影响构建系统或外部依赖项的更改 - `ci`：对我们的 CI 配置文件和脚本的更改 - `perf`：提高性能的代码更改 - `revert`：回退到某个 commit #### 示例 ``` feat: add hat wobble ^--^ ^------------^ | | | +-> Summary in the present tense. | +-------> Type: Feature addition fix: fixes #xxx ^--^ ^------------^ | | | +-> Reference to the GitHub issue. | +-------> Type: Bug fix ``` 参考： - https://www.conventionalcommits.org/en/v1.0.0/ - https://gist.github.com/joshbuchea/6f47e86d2510bce28f8e7f42ae84c716#file-semantic-commit-messages-md - https://www.conventionalcommits.org/ - https://seesparkbox.com/foundry/semantic_commit_messages - http://karma-runner.github.io/1.0/dev/git-commit-msg.html ## 部署到 Dockerhub Docker 镜像部署通过预定义的 GitHub Action 工作流自动处理。 要触发部署，请创建一个版本标签并将其推送到仓库： ``` git push origin tag v ``` 新的 Docker 镜像随后将可在 Docker Hub 上的相应版本标签下找到。 ## 许可证 请参阅 [LICENSE.md](/LICENSE.md)

标签：BrowserStack, GDPR合规, GitHub Actions, Semgrep, SOC2合规, Web服务器, WordPress安全扫描, 人工智能安全, 入职管理, 单元测试, 单点登录, 可插拔模块, 合规性, 后端开发, 安全扫描, 审计跟踪, 开源, 时序注入, 权限撤销, 权限管理, 模型越狱, 离职管理, 自动笔记, 访问管理, 请求拦截, 资产盘点, 身份与访问控制, 运维自动化, 逆向工具, 门户网站, 集中式管理