为 GitLab Pipeline 安全地检索 Azure 租户 ID、客户端 ID 和客户端密钥
我正在设置GitLab管道来运行一些TerraForm配置,以在我们的Azure AD和Hashicorp Vault实例之间启用OIDC身份验证。该解决方案的概念证明已成功实施。
为了保护一些消耗的敏感数据,需要在运行时牢固地存储以下Azure凭据,加密并注入GitLab管道中:
- 租户ID
- 客户端
- 客户端秘密,
因此我们希望识别并实施理想的解决方案,以实现一个理想的解决方案,以实现一个理想的解决方案实现此目标,并将很容易地使用AWS,Azure或Hashicorp保管库考虑安全的存储选项,这都是我们技术堆栈的一部分。有什么建议或建议吗?
I am setting up a GitLab pipeline to run some Terraform configuration to enable OIDC authentication between our Azure AD and HashiCorp Vault instances. A proof of concept of this solution has been successfully implemented.
To protect some of the sensitive data consumed, there is a requirement to store the following Azure credentials securely, encrypted and injected into the GitLab pipeline when run:
- Tenant ID
- Client ID
- Client Secret
We'd therefore like to identify and implement an ideal solution to achieve this objective and will readily consider secure storage options using AWS, Azure or HashiCorp Vault which are all part of our tech stack. Any suggestions or recommendations?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
房客ID和客户ID并不是特别敏感的信息,因此我认为您不必安全地存储/访问这些信息。
为了保护客户的秘密,您可以使用组变量。
将秘密保存到诸如Azure密钥库之类的服务上是可能的,但是您需要一个应用程序注册(另一个客户ID和秘密)才能再次检索它。
The Tenant ID and Client ID are not particularly sensitive information, so I don't think you need to necessarily store/access these securely.
To protect the client secret, you can use group variables.
Saving the secrets to services like Azure Key Vault would be possible, but you'd need an application registration (another client id and secret) to retrieve it again.
这就是秘密的事情:您必须从某个地方开始。这个问题通常称为“安全介绍”。让我们遵循这条路。
它首先是在Azure-AD中注册Vault,从而为您提供关注的值。如果您在管道中的Azure AD中注册Vault,最好的是保持值并立即重复使用它们以配置Vault的OIDC Auth后端。
但是根据您的要求,您无法将其存储在您的Terraform状态下。每年左右,也存在定期更改客户秘密的问题。
当您在Azure-AD中注册Vault时,请在版本2 KV商店中写下凭据,并具有受限的策略。即使只有客户的秘密是一个秘密,我们仍将凭据存储在这样的文档中:
然后,我们从金库中读取这些值,并使用它们来配置OIDC Auth后端。当客户端秘密更改时,将其作为秘密的新版本,并通过配置管道的下一个运行来挑选。
That's the thing with secrets: You have to start somewhere. That problem is often called "secure introduction". Let's follow that trail.
It starts with registering Vault in Azure-AD, giving you back the values you are concerned with. If you register Vault in Azure-AD in your pipeline, the best is to hold on to the values and reuse them right away to configure Vault's OIDC auth backend.
But based on your requirements, you can't store them in your Terraform state. There is also the problem of changing the client secret on a regular basis, say every year or so.
When you register Vault in Azure-AD, write the credentials in a version 2 KV store, with restricted policies. Even though only the client secret is a secret, we store the credentials in a document like this:
We then read these values from Vault, and use them to configure the OIDC auth backend. When the client secret change, there are put as a new version of the secret and are picked up by the next run of the configuration pipeline.
OIDC 不需要在 GitLab 中存储或访问客户端密钥。这是使用 OIDC 的主要好处:您不必在 GitLab 中存储/访问任何机密。您只需使用
$CI_JOB_JWT_V2
令牌即可。这不是对您有关安全访问凭据的问题的直接答案,其他答案已回答了该问题。但我将向您展示如何设置 OIDC,这样您甚至不必首先存储客户端密钥。
首先,您需要在 Azure 中注册一个应用程序。您可以按照 这些说明用于注册应用程序并创建服务主体。
执行此操作后,记下应用程序(客户端)ID 和目录(租户)ID 的值(位于应用程序概述窗格中)。步骤 3 将需要这些值。
其次,您需要将联合凭据添加到应用程序的服务主体。在 Azure 门户中,转到注册的应用程序 -> 您的应用程序。在侧边栏中,选择证书和证书秘密。在联合凭据选项卡下,单击“添加凭据”按钮
使用以下参数进行凭据配置:
联合凭据 sceanrio:其他颁发者< br>
发行者:您的 gitlab URL,例如
https://gitlab.example.com
主题标识符:要匹配的
sub
声明的值。例如,要允许contoso/myproject
项目的main
分支上的作业使用此服务主体,请使用project_path:contoso/myproject:ref_type:branch:参考:主要
名称:联合凭据的任何描述性名称(例如
contoso-myproject-main
)描述:可选,联合凭据的描述。
受众:您的 GitLab URL,例如
https://gitlab.example.com
最后,您现在可以使用 OIDC 从 gitlab 登录 Azure:
记下客户端 ID 和租户 ID不是敏感信息,因此可以合理地将它们直接添加到您的 YAML 中。
OIDC does not require storing or accessing the client secret in GitLab. That's the primary benefit of using OIDC: you do not have to store/access any secrets in GitLab. You just use the
$CI_JOB_JWT_V2
token.This is not a direct answer to your question about securely accessing credentials, which has been answered by other answers. But I will show you how to setup OIDC such that you don't even have to store client secret in the first place.
First, you will need to register an Application in Azure. You can do this by following these instructions to register an application and create a service principal.
After doing this, make note of the values for Application (client) ID and Directory (tenant) ID (found in the application Overview pane). These values will be needed for step 3.
Second, you will need to add the federated credentials to the application's service principal. In the Azure portal, go to registered apps -> your application. In the sidebar, select Certificates & secrets. Under the Federated credentials tab, click the "Add credential" button
Use the following parameters for the credential configuration:
Federated credential sceanrio: Other issuer
Issuer: your gitlab URL e.g.
https://gitlab.example.com
Subject Identifier: The value of the
sub
claim to match. For example, to allow jobs on themain
branch of thecontoso/myproject
project to use this service principal, useproject_path:contoso/myproject:ref_type:branch:ref:main
Name: Any descriptive name for the federated credental (e.g.
contoso-myproject-main
)Description: Optional, a description for the federated credential.
Audience: your GitLab URL e.g.
https://gitlab.example.com
Finally, you can now use OIDC to login to Azure from gitlab:
Note the client ID and tenant ID are not sensitive pieces of information, so they can reasonably be added directly to your YAML.