大规模雪花访问控制

越来越多的公司将 Snowflake 作为其 data platforms 的核心。即使是托管解决方案，您也必须管理环境。这可能是一个挑战，尤其是对大公司而言。.

挑战之一是 门禁. .它是任何 data governance 计划的关键部分。雪花计划提供 开箱即用的功能 来帮助应对这一挑战。但是，当您拥有几十个用户和数 TB 的 data 时，仅有内置功能是不够的。您需要考虑管理账户的策略。.

我们去过那里。对于其中一个 我们的客户, 我们管理着一个拥有 50 多个活跃用户的账户。我们设计了一个解决方案来扩展访问控制管理。.

本文将介绍过去一年的主要学习成果。.

在我们加入公司之前，账户已经建立起来，很多好的想法也已付诸实施。. 自定义角色 已经创建。对用户进行了细致的管理。但也存在一些限制：

我们创建了一个新的系统来管理出入控制和克服这些缺陷。.

首先，我们取消了所有用户的默认角色授权（SYSADMIN、USERADMIN......）......只有少数人能够担任这些角色。他们就是负责管理的人。.

其次，我们创建了一个基于自定义角色的访问控制框架。我们定义了两种自定义角色：

我们选择在 data 基底级. .通过零拷贝克隆，它可以轻松地将权限从一个环境复制到另一个环境。这也是 权衡 我们赋予最终用户的灵活性与严格执行最小特权原则之间的矛盾。.

在 database 一级，我们定义了 3 个级别的访问角色：

我们在仓库访问中也采用了类似的策略，有两种角色：

下面是我们的框架说明。箭头代表补助金。.

此时，我们对如何管理权限有了更好的认识，但在用户管理方面也遇到了问题。.

我们设立了 单点登录 以允许 Snowflake 用户 通过 Azure 活动目录 (AAD) 登录. .因此，我们消除了维护两个用户 database 的复杂性，而且离岗流程也更加稳健。事实上，我们只需在 AAD 中禁用用户，删除操作就会自动复制到 Snowflake 中。.

由于 AD 组和 Snowflake 中的角色之间存在映射关系，因此我们可以为创建的每个用户授予一个角色。我们对每个新用户都遵循相同的流程。.

这是真正的人类用户的流程，但它并没有解决本文开头提到的一个局限性：在自动工作中使用个人凭据。.

因此，我们推出了 服务账户. .服务账户管理与我们刚才描述的非常相似。唯一不同的是，我们为每个服务账户创建了一个功能角色。有一个 服务账户与其角色之间的一一对应关系. .因此，我们严格限制每个服务账户的权限范围。.

这些步骤都是很大的改进。一切都记录在案。团队迅速采用了新框架。我们很高兴。.

但是，我们仍然要花费大量时间手动授予访问权限，而且由于是手动操作，还很容易出错。显然，我们需要一个工具来自动完成这些任务。.

我们有几个选择：

我们终于用 Python 创建了 CLI。.

我们更喜欢使用 Terraform 部署基础架构，而且只部署基础架构。开始使用 Terraform 管理用户和权限时，可能会出现意想不到的行为。例如，秘密轮换就很难管理。.

我们喜欢 bash，但仅限于临时和简单的操作。在这里，我们需要加载配置文件、与 Snowflake API 交互并操作 data 结构。这是可能的，但从长远来看很难维护。.

除此以外，我们还需要可靠性。实现这一点的方法之一就是编写测试。这在 Python 等编程语言中比较容易实现。.

当您执行该工具时，会在幕后发生以下情况。.

根据设计，该工具不会创建已经存在的角色。权限也是如此。工具会计算 配置与远程环境之间的差异 并进行必要的更改。这使我们能够避免任何停机时间。.

我们最初在本地运行该工具。但这可能会导致一些问题。例如，我们可能会遇到两个工程师试图同时进行修改的冲突。因此，我们设置了一个 工作流基于 Azure DevOps (ADO) 的 CI/CD 功能.

注：我们使用的是 ADO，但也可以使用 GitHub、GitLab 或 Bitbucket。.

下面是最终流程。.

这种完全自动化的工作流程效果非常好。测试在 CI 管道的早期就能捕捉到默认设置。强制审查也是防止事故发生的一种方式。.

此外，拉取请求也是对所有需求的一种记录。.

我们开始使用这个解决方案还不到一年。虽然实施初期需要投入一定的时间，但这是完全值得的。.

现在，我们把更多的时间花在了与用户讨论他们的要求上，而不是实际实现上。大多数请求只需约 10 行 YAML 即可解决。这非常高效，而且扩展性很好。我们仍然欢迎新用户的加入，我们可以满足他们的需求。此外，我们还解决了最初的问题。因此，这是一次成功！