VSTS secret variables are actually secret or not?
VSTS build definition has the option to create a secret variable. How secret is that variable? Is it safe to store the user credentials which is specific to a set of users? Can other users (who are not authorized to do it) can decrypt that variable?
I came across this article.
Assuming users have build modification access then is it possible to decrypt the variable?
azure-devops azure-pipelines azure-pipelines-build-task edited Nov 23 '18 at 14:29
jessehouwing
67.7k9163237
asked Nov 23 '18 at 11:54
Atul SurekaAtul Sureka
1,06532243
add a comment |
VSTS build definition has the option to create a secret variable. How secret is that variable? Is it safe to store the user credentials which is specific to a set of users? Can other users (who are not authorized to do it) can decrypt that variable?
I came across this article.
Assuming users have build modification access then is it possible to decrypt the variable?
azure-devops azure-pipelines azure-pipelines-build-task edited Nov 23 '18 at 14:29
jessehouwing
67.7k9163237
asked Nov 23 '18 at 11:54
Atul SurekaAtul Sureka
1,06532243
add a comment |
VSTS build definition has the option to create a secret variable. How secret is that variable? Is it safe to store the user credentials which is specific to a set of users? Can other users (who are not authorized to do it) can decrypt that variable?
I came across this article.
Assuming users have build modification access then is it possible to decrypt the variable?
azure-devops azure-pipelines azure-pipelines-build-task edited Nov 23 '18 at 14:29
jessehouwing
67.7k9163237
asked Nov 23 '18 at 11:54
Atul SurekaAtul Sureka
1,06532243
VSTS build definition has the option to create a secret variable. How secret is that variable? Is it safe to store the user credentials which is specific to a set of users? Can other users (who are not authorized to do it) can decrypt that variable?
I came across this article.
Assuming users have build modification access then is it possible to decrypt the variable?
azure-devops azure-pipelines azure-pipelines-build-task azure-devops azure-pipelines azure-pipelines-build-task edited Nov 23 '18 at 14:29
jessehouwing
67.7k9163237
asked Nov 23 '18 at 11:54
Atul SurekaAtul Sureka
1,06532243
edited Nov 23 '18 at 14:29
jessehouwing
67.7k9163237
asked Nov 23 '18 at 11:54
Atul SurekaAtul Sureka
1,06532243
edited Nov 23 '18 at 14:29
jessehouwing
67.7k9163237
edited Nov 23 '18 at 14:29
jessehouwing
67.7k9163237
edited Nov 23 '18 at 14:29
jessehouwing
67.7k9163237
67.7k9163237
asked Nov 23 '18 at 11:54
Atul SurekaAtul Sureka
1,06532243
asked Nov 23 '18 at 11:54
Atul SurekaAtul Sureka
1,06532243
asked Nov 23 '18 at 11:54
Atul SurekaAtul Sureka
1,06532243
1,06532243
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
Variables stored are as secure as the agent that runs the build and the integrity of your build definition.
Like you said, if a user can modify the Build Definition and has access to the secret they can pass it to a PowerShell or a Curl task etc. Or if the user can take control over a Build Task's script they can iterate all available secrets (build tasks are considered trusted by the Build System).
Consider that everyone who has write-access over the work directories of the agent can access all secrets that are available to the Build Definitions that execute on the build agent. They can change the scripts used by Build Tasks and thus gain the same level of trust. Any build that runs after this change and until a new version of the task is pushed to the agent will be compromised in this scenario. In theory can every build definition "infect" the _tasks folder of the agent as well. Best way to protect against this is to use the Hosted Pool or to regularly reset your agent's VMs.
YAML build definitions combined with Pull-Requests give you more control over the Change/approval process of build definitions.
Using a Variable Library you can reduce the number of people who can add secret variables to their Build Definition.
You must secure the Agent Pools and the Variable Libraries/Build Definitions in such ways that only limited and trusted users can access these resources. Optionally use single-use passwords that expire after a short time or temporarily grant these permissions.
Remember that all changes to Build Definitions and Variable Libraries and Scripts in the Git Repository are tracked.
The alternate ways to get access to the secrets do not apply to Azure DevOps as none have access to the Application Tier in Azure and access is strictly monitored by Microsoft.
answered Nov 23 '18 at 13:44
jessehouwingjessehouwing
67.7k9163237
For more security use something like Azure Key Vault docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/…
– Colin B
Nov 23 '18 at 18:32
1
Once retrieved from keyvault they're equally vulnerable.
– jessehouwing
Nov 23 '18 at 18:33
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53446247%2fvsts-secret-variables-are-actually-secret-or-not%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Variables stored are as secure as the agent that runs the build and the integrity of your build definition.
Like you said, if a user can modify the Build Definition and has access to the secret they can pass it to a PowerShell or a Curl task etc. Or if the user can take control over a Build Task's script they can iterate all available secrets (build tasks are considered trusted by the Build System).
Consider that everyone who has write-access over the work directories of the agent can access all secrets that are available to the Build Definitions that execute on the build agent. They can change the scripts used by Build Tasks and thus gain the same level of trust. Any build that runs after this change and until a new version of the task is pushed to the agent will be compromised in this scenario. In theory can every build definition "infect" the _tasks folder of the agent as well. Best way to protect against this is to use the Hosted Pool or to regularly reset your agent's VMs.
YAML build definitions combined with Pull-Requests give you more control over the Change/approval process of build definitions.
Using a Variable Library you can reduce the number of people who can add secret variables to their Build Definition.
You must secure the Agent Pools and the Variable Libraries/Build Definitions in such ways that only limited and trusted users can access these resources. Optionally use single-use passwords that expire after a short time or temporarily grant these permissions.
Remember that all changes to Build Definitions and Variable Libraries and Scripts in the Git Repository are tracked.
The alternate ways to get access to the secrets do not apply to Azure DevOps as none have access to the Application Tier in Azure and access is strictly monitored by Microsoft.
answered Nov 23 '18 at 13:44
jessehouwingjessehouwing
67.7k9163237
For more security use something like Azure Key Vault docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/…
– Colin B
Nov 23 '18 at 18:32
1
Once retrieved from keyvault they're equally vulnerable.
– jessehouwing
Nov 23 '18 at 18:33
add a comment |
Variables stored are as secure as the agent that runs the build and the integrity of your build definition.
Like you said, if a user can modify the Build Definition and has access to the secret they can pass it to a PowerShell or a Curl task etc. Or if the user can take control over a Build Task's script they can iterate all available secrets (build tasks are considered trusted by the Build System).
Consider that everyone who has write-access over the work directories of the agent can access all secrets that are available to the Build Definitions that execute on the build agent. They can change the scripts used by Build Tasks and thus gain the same level of trust. Any build that runs after this change and until a new version of the task is pushed to the agent will be compromised in this scenario. In theory can every build definition "infect" the _tasks folder of the agent as well. Best way to protect against this is to use the Hosted Pool or to regularly reset your agent's VMs.
YAML build definitions combined with Pull-Requests give you more control over the Change/approval process of build definitions.
Using a Variable Library you can reduce the number of people who can add secret variables to their Build Definition.
You must secure the Agent Pools and the Variable Libraries/Build Definitions in such ways that only limited and trusted users can access these resources. Optionally use single-use passwords that expire after a short time or temporarily grant these permissions.
Remember that all changes to Build Definitions and Variable Libraries and Scripts in the Git Repository are tracked.
The alternate ways to get access to the secrets do not apply to Azure DevOps as none have access to the Application Tier in Azure and access is strictly monitored by Microsoft.
answered Nov 23 '18 at 13:44
jessehouwingjessehouwing
67.7k9163237
For more security use something like Azure Key Vault docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/…
– Colin B
Nov 23 '18 at 18:32
1
Once retrieved from keyvault they're equally vulnerable.
– jessehouwing
Nov 23 '18 at 18:33
add a comment |
Variables stored are as secure as the agent that runs the build and the integrity of your build definition.
Like you said, if a user can modify the Build Definition and has access to the secret they can pass it to a PowerShell or a Curl task etc. Or if the user can take control over a Build Task's script they can iterate all available secrets (build tasks are considered trusted by the Build System).
Consider that everyone who has write-access over the work directories of the agent can access all secrets that are available to the Build Definitions that execute on the build agent. They can change the scripts used by Build Tasks and thus gain the same level of trust. Any build that runs after this change and until a new version of the task is pushed to the agent will be compromised in this scenario. In theory can every build definition "infect" the _tasks folder of the agent as well. Best way to protect against this is to use the Hosted Pool or to regularly reset your agent's VMs.
YAML build definitions combined with Pull-Requests give you more control over the Change/approval process of build definitions.
Using a Variable Library you can reduce the number of people who can add secret variables to their Build Definition.
You must secure the Agent Pools and the Variable Libraries/Build Definitions in such ways that only limited and trusted users can access these resources. Optionally use single-use passwords that expire after a short time or temporarily grant these permissions.
Remember that all changes to Build Definitions and Variable Libraries and Scripts in the Git Repository are tracked.
The alternate ways to get access to the secrets do not apply to Azure DevOps as none have access to the Application Tier in Azure and access is strictly monitored by Microsoft.
answered Nov 23 '18 at 13:44
jessehouwingjessehouwing
67.7k9163237
Variables stored are as secure as the agent that runs the build and the integrity of your build definition.
Like you said, if a user can modify the Build Definition and has access to the secret they can pass it to a PowerShell or a Curl task etc. Or if the user can take control over a Build Task's script they can iterate all available secrets (build tasks are considered trusted by the Build System).
Consider that everyone who has write-access over the work directories of the agent can access all secrets that are available to the Build Definitions that execute on the build agent. They can change the scripts used by Build Tasks and thus gain the same level of trust. Any build that runs after this change and until a new version of the task is pushed to the agent will be compromised in this scenario. In theory can every build definition "infect" the _tasks folder of the agent as well. Best way to protect against this is to use the Hosted Pool or to regularly reset your agent's VMs.
YAML build definitions combined with Pull-Requests give you more control over the Change/approval process of build definitions.
Using a Variable Library you can reduce the number of people who can add secret variables to their Build Definition.
You must secure the Agent Pools and the Variable Libraries/Build Definitions in such ways that only limited and trusted users can access these resources. Optionally use single-use passwords that expire after a short time or temporarily grant these permissions.
Remember that all changes to Build Definitions and Variable Libraries and Scripts in the Git Repository are tracked.
The alternate ways to get access to the secrets do not apply to Azure DevOps as none have access to the Application Tier in Azure and access is strictly monitored by Microsoft.
answered Nov 23 '18 at 13:44
jessehouwingjessehouwing
67.7k9163237
edited Nov 23 '18 at 14:20
answered Nov 23 '18 at 13:44
jessehouwingjessehouwing
67.7k9163237
answered Nov 23 '18 at 13:44
jessehouwingjessehouwing
67.7k9163237
answered Nov 23 '18 at 13:44
jessehouwingjessehouwing
67.7k9163237
67.7k9163237
For more security use something like Azure Key Vault docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/…
– Colin B
Nov 23 '18 at 18:32
1
Once retrieved from keyvault they're equally vulnerable.
– jessehouwing
Nov 23 '18 at 18:33
add a comment |
For more security use something like Azure Key Vault docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/…
– Colin B
Nov 23 '18 at 18:32
1
Once retrieved from keyvault they're equally vulnerable.
– jessehouwing
Nov 23 '18 at 18:33
For more security use something like Azure Key Vault docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/…
– Colin B
Nov 23 '18 at 18:32
For more security use something like Azure Key Vault docs.microsoft.com/en-us/azure/devops/pipelines/tasks/deploy/…
– Colin B
Nov 23 '18 at 18:32
1
1
Once retrieved from keyvault they're equally vulnerable.
– jessehouwing
Nov 23 '18 at 18:33
Once retrieved from keyvault they're equally vulnerable.
– jessehouwing
Nov 23 '18 at 18:33
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53446247%2fvsts-secret-variables-are-actually-secret-or-not%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
