ASP.NET Core has a great feature to store user settings securely.
It works great on OSX (and Linux, Windows), stores data in JSON:
~/.microsoft/usersecrets/<userSecretsId>/secrets.json
Is it working in the cloud (Cloud Foundry) too? If yes, then were are the values stored?
Secrets exists for safe storage during development by helping prevent sensitive data from being storing in code / checked into source control.
The Secret Manager tool does not encrypt the stored secrets and should not be treated as a trusted store. It is for development purposes only. The keys and values are stored in a JSON configuration file in the user profile directory.
In Cloud you can directly use Environment Variables for that.
Related
I have a react-native app that communicates with a server that makes calls to stripe for payment processing/customer creation. I want to ensure that requests are coming only from my app. so i figured i could create a token of sorts on the client, and encrypt it with a special key using b-crypt, then on the server side when the request comes in with the encrypted token as a parameter, i can decrypt that token with the same special key.
i understand the optimal place to store this key is in the env variables server-side, but how do you manage security of a secret key client-side in a react-native app?
There are several ways to store keys on the client side.
The easiest way is to use the Async storage which stores data in a key value pair.
The problem with Async storage is that its nor encrypted so it wont suit your requirement.
The other option is to use the react-native-keychain library which stores the passwords or keys in the securely in the keychain of IOS and keystore in Android. The security part will be managed by the operating system. So this is an approach that can be recommended for your requirement.
There are multiple ways to do this, these are just two options.
After further research, I ended up revoking the accepted status of #GuruparanGiritharan. his solution (react-native-keychain) dealt with storing passwords in an OS's keychain implementation. this ended up not being the solution for my question. as my question deals with storing secrets keys in a way they wouldn't be visible in binary, de-compiling situation.
What I did was research key management services. I found this:
Handling secrets with dotenv
In Node.js secrets are usually loaded from env files using the dotenv
module. This is done in order to separate the secrets from source
code. For example an env file might look like this (reference below):
DB_HOST=localhost
DB_USER=root
DB_PASS=s1mpl3
Now doing this in a context (potentially development) where you dont need to implement continuous integration, it's referred to a "manual provisioning"
My issue (admittedly, I did not specify a production environment in my question) is when it comes to a production environment, in my case, with visual studio app center (a CI option for React-Native apps)
Continuing on this site for an option for key management services:
While this removes hardcoded secrets from source code, it doesn’t
solve your problem completely; Now you need to find a way to provision
your app with the .env file.
This guide will show how you can remove the secrets from the .env file
altogether, so that it can be safely checked into source control and
shipped with your application.
This guide is discussing how to implement key management in the context of a production environment with continuous integration. This approach is relatively simple and straightforward, as all you need to do is create an .env file, add the keys with a variable, and add (in this tool's case) an additional run script to your main node.js start script.
Tool mentioned: SecretHub
https://secrethub.io/docs/guides/nodejs/
I am using database connector component, with vault component to store the database credentials. Now as per the documentation of both components i have created different properties file for each environment to store the encrypted credentials for diff env.
Following is the structure of my mule project
Now the problem with this structure is that i have to build new deployable zip file whenever i have to update the database credentials for any environment.
I need a solution where i can keep all credentials encrypted and centralized and i don't have to create a build every time after updated the credentials, We can afford to restart the server, but building new zip and deploying is really cumbersome.
Second problem we have this approach is a developer needs to know the production db to update it in properties file, this is also a security issue.
Please suggest alternate approach for credentials management for mule projects.
I'm going to recommend you do NOT try to change the secure solution provided to you by MuleSoft. To alleviate the need for packaging and deployment, you would have to extract the properties files outside of the deployment and this would be a huge risk. Regardless of where you store the property files within the deployment if you change the files, you have to package and re-deploy. I see the only solution to your problem as moving the files outside of the deployment and securely storing them. Mule has provided a solution while it may be cumbersome, they are securing these files first with encryption and secondly within the server container. You can move out the property files but you have to provide a custom implementation and you will be assuming great risk to your protected resources.
Set a VM arguement e.g. environment.type=local for local machine on your anypoint studio.
Read this variable in wherever you are reading your properties file in a way that environment type is read dynamically such as below.
" location="classpath:properties/sample-app-${environment.type}.properties" doc:name="Secure Property Placeholder"/>
In order to set the environment type on your production server(or wherever you are using mule runtime), open \conf\wrapper.conf and add the arguement wrapper.java.additional.=-Dserver.type=production. If you already have any property in this file, you may need to set the value of n appropriately. For example 13 or 14.
This way you don't need to generate different deployment artefacts for different environment because correct properties file is picked by using environment specific VM arguement.
So, a common practice these days is to put connection strings & passwords as environment variables to avoid their being placed into a file. This is all fine and dandy, but I'm not sure how to make this work when trying to set up a continuous deployment workflow with some configuration management tool such as Salt/Ansible or Chef/Puppet.
Specifically, I have the following questions in environments using the above mentioned configuration management tools:
Where do you store connection strings/passwords/keys separate from codebases?
Do you keep those items in a code-repo of some type (git, etc.)?
Do you use some structure built-in to your tool?
How do you keep those same items secure?
Do you track changes/back-up these items, and if so, how?
In Chef you can
store passwords or API tokens in either encrypted data bags or using chef-vault. They are then decrypted while chef does the provisioning (with encrypted data bags using a shared secret, with chef-vault using the existing PKI of Chef client).
set environment variables when calling external software using the environment parameter of e.g. the execute resource.
not sure, what to write here -- I'd say you don't really manage them. This way you set the variables only for the command that needs it, not e.g. for the whole chef run.
With puppet, the preferred way is probably to store the secrets in Hiera files, which are just plain YAML files. That means that all secrets are stored on the master, separate from the manifest files.
truecrypt virtual encrypted disks are cross-platform and independent of tooling. Mount it read-write to change the secrets in the files it contains, unmount it and then commit/push the encrypted disk image into version control. Mount read-only for automation.
ansible-vault can be used to encrypt sensitive data files. A CI server like Jenkins however is not the safest place to store access credentials. If you add Hashicorp Vault and Ansible Tower/AWX, then you can provide a secure solution for several teams.
I am doing some small devices running Debian. They need to sync a S3 bucket to a folder locally. I Have installed S3Tools and s3cmd sync seems to be the perfect tool. But I have to supply the Access Credentials and that seems VERY insecure. I will not be controlling the units once they ship so I need to somehow use the tool without supplying the credentials - AND I need to make sure the credentials can not delete in the bucket.
Does anyone have an idea as to how I go about this?
Regards, Jacob
Use IAM. It allows creation of AWS credentials with predefined permissions, which are under your control.
So you will create one identity per device. You are free to restrict access only to some buckets, keys.
You will not be able updating "device" credentials on your devices (this is simply your constrain), but in case some of your credentials will turn out as compromised, you still have the option to block it via IAM.
And for your primary "root" identity, I strongly recommend using two factor authentication (and of-course never put it to a device, you do not have control of).
I want to run a Tomcat app in Cloudbees. This app accesses some private and confidential properties from the file system. How could I access a file system on Cloudbees? Please note that it should be highly protected, e.g. 700 or similar.
Regards,
Marco
RUN#Cloud platform don't provide a persistent (nor distributed) filesystem. So you can't use it to as canonical store for those files, but need to use an external file store to match your security requirements, and copy them as application is starting (or lazy-load) to java.io.temp directory. As files are stored on RUN#Cloud there is no security issue as your server instance is fully isolated, and files will be deleted after application undeployed/passivated
So you can use Amazon S3 or comparable to store files
Another option is for you to attach properties to the RUN#Cloud instance as configuration parameters, and access them as System properties. See http://wiki.cloudbees.com/bin/view/RUN/Configuration+Parameters
If they data is modest in size - you could consider using properties - using the CLI you can set them using
bees config:set propertyName=value
you can then access that as a System property (for example) in your application. The properties themselves are stored encrypted by cloudbees.
I've actually moved to OpenShift since then and I solved the problem. Thank you for your answers