I have a case where the RunDeck scripts do need some credentials in order to run. Obviously we do not want to store these in the job definitions because these are visible and also stored in SCM.
While I was able to use the Key Storage vault to put these secrets in, I was not able to find a way to access them from the job itself.
Rundeck 2.6.2 (released 2015-12-02) allows you to specify key storage secrets as default values for secure job options. See Secure Options using Key Storage
Related
I need to automate a task and I'm going to store some variables and secrets that I need for future scripts.
Is there a way that to access my key vault without using the command Connect-AzConnect, and without using a specific user to do so?
Right now I'm using the command Get-AzKeyVaultSecret, I've noticed the argument -DefaultProfile, but I'm not sure how to use it.
Thank you in advance.
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?
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.
I have configured my service fabric services to use Azure Key Vault for configuration. If, after the app is deployed, I change the config in Key Vault, how do I then restart the affected service so it can pick up the new config value?
Or is there another way altogether?
The best way to handle configuration on SF is use your application parameters file for this, if you use a continuous deployment pipeline like VSTS, you could use release variables to set these values for you and deploy a new version of your configuration file and let SF do the rest.
But in case you still need to use Key vault:
if you are using asp.net core, Using Azure Key Vault to store secrets are like loading configuration files, the values are cached until you reload it.
You can use the IConfigurationRoot.Reload() to reload the secrets from your key vault new values. Check it Here
The trick now is to make it automatically you have to:
Enable Key Vault Logging to track the changes, this will emit logs once you update the key vault. check it here and here .
And then:
Create an endpoint in your API to be called and refresh the secrets. Make it secure to avoid abuse.
Create an Azure function to process these logs and trigger the endpoint
Or:
Create a message queue to receive the command and the system read the message to refresh the settings
Or:
Make a timer to refresh on specific periods(I would not recommended this approach because you might end up with outdated config, but it is easy and useful for quick test scenarios, not production)
Or if you prefer more custom designed solution, you could create your own ConfigurationProvider based on KeyVault and do the cache logic according to your app architecture and you don't have to bother with the rest. Please refer to the Asp.Net source here for this.
The documented way to provide configuration to your services is by using the 'configuration' part of your application package.
As this is versioned, it can be upgraded, without requiring your services to be upgraded or even be restarted.
More info here and here.
Is it possible to use AWS KMS and a tool like credstash without the use of EC2 or equivalent or does it rely solely on IAM roles?
I've got a server elsewhere where I am testing some things out and ultimately I will be looking at migrating an app to EC2 etc. to make use of scaling. But for now whilst I'm setting up my deployment pipeline etc. I wondered if it was still possible to make use of KMS on my non-aws provisioned server?
The only possible way I can think of is by installing the AWS CLI tools on the server in question. Does this sounds like the right approach?
What #Viccari said is correct (in the comments). In terms of what you want to do (store passwords), the AWS Parameter Store would be a good fit for you. See https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html for more information. The guide explicitly calls out your use-case:
Parameter Store offers the following benefits and features.
Use a secure, scalable, hosted secrets management service (No servers to manage).
In the end, if you end up using Parameter Store or KMS, you will need some sort of credentials stored somewhere to grab an AWS STS token to use to call the underlying AWS services. If working outside of AWS EC2, you will need the AWS Access Key and AWS Secret Key from an IAM user. If you are in EC2, the IAM instance role will magically provide you the credentials and use that role to call those AWS services. The AWS SDK does this for you behind the scenes.
But, as you state, you don't want to run this in EC2 (to save money, or other reasons). The quickest way to store these credentials is to have them in a un-tracked file (added to your .gitignore) you can source from as environment variables, which your program will then read. This allows you to do local testing, and easily run it in EC2
with zero code changes. See https://docs.aws.amazon.com/cli/latest/userguide/cli-environment.html for what variables to set. Note that this doc talks about the CLI; the SDK's follow the same behavior.
I have a console app in dotnet core. I use appsettings.Development.josn and appsettings.Staging.json for dev and staging environment but for the production environment i use the UserSecrets. I have two problem when the app is running on production env it does not create UserSecrets in the %Appdata%/Microsoft so I have to make it manually and then it starts to work.
Another part of my question is this:
today I found out that microsoft wrote here
The Secret Manager tool is used only in development. You can safeguard Azure test and production secrets with the Microsoft Azure Key Vault configuration provider. See Azure Key Vault configuration provider for more information.
I dont have Azure. What can I use in production if I am not supposed to use the UserSecrets.
While environment variables are one of the most used options in web development and The Twelve Factor App documents states: "Store config in the environment" there are some reasons why this may not be the best approach:
the environment is implicitly available to the process and it's hard to track access. As a result, for example, you may face with situation when your error report will contain your secrets
The whole environment is passed down to child processes (if not explicitly filtered). So your secret keys are implicitly made available to any 3rd-party tools that may be used.
All this are one of the reasons why products like Vault become popular nowadays.
So, yes, you may use environment variables, but be aware)
For storing secure data in your app, if you're using Azure, So Azure KeyValut is your answer, you can see Azure Microsoft Azure Key Valut,
In case you're using K8S, you can store it on CSI driver
Or system OS environment variables