regarding this post:
Git/Heroku - How to hide my SECRET_KEY?
follow up question here:
when you set: heroku config:set SECRET_KEY="..."
there is no way for a third party to access the entered secret key, correct?
So in the example provided they are setting the secret using an operating system (OS) environment variable. The only way for someone to access your secret key is if it's exposed to the client-side or they have access to your dyno or your OS.
Using heroku environment variables is incredibly secure and there's really nothing to worry about in this instance.
Related
I'm deploying my Spring boot application into Heroku server via git deployment. There are passwords and api secrets in my application.yml. Those properties are encrypted with Jasypt. One thing I don't understand is: how to pass jasypt decryption password into deployed application for startup?
Heroku has Config Vars, but they do not seem secure, considering that all of them could be revealed on the dashboard
Is there a secure way to send a password into deployment?
the Config Vars is the accepted mechanism to pass runtime information to the apps upon deployment;
It is pretty secure if the access to the Dashboard is controlled of course (those settings are never exposed or logged), only the owner can reveal the values.
I want to write cloud-init script which initializes REX-Ray docker plugin(A service which uses AWS credentials on its configuration).
I have considered the following methods. However, these methods have some disadvantages.
Hard code access key/secret key in cloud-init script.
Problem: This is not secure.
Create IAM role, then refer access key, secret key from instance meta data.
Problem: Access key will expires in a certain period.
So I need to restart REX-Ray daemon process, which causes service temporary unavailable.
Please tell me which is better way to refer access key/secret key, or another way if it exists.
Thanks in advance.
The docker plugin should get the credentials automatically. You don't have to do anything. Do not set any environment variables for AWS credentials.
AWS CLI / AWS SDK will get the credentials automatically from the meta data server.
You can use the following method of authentication
Environment variables
Export both access and secret keys in environment environment as follow:
$ export AWS_ACCESS_KEY_ID="anaccesskey"
$ export AWS_SECRET_ACCESS_KEY="asecretkey"
Shared Credential file
You can use an AWS credentials file to specify your credentials. The default location is $HOME/.aws/credentials on Linux and OS X, or "%USERPROFILE%.aws\credentials" for Windows users. If terraform fail to detect credentials inline, or in the environment, Terraform will check this location
You can optionally specify a different location in the configuration by providing the shared_credentials_file attribute as follow
provider "aws" {
region = "us-west-2"
shared_credentials_file = "/Users/tf_user/.aws/creds"
profile = "customprofile"
}
https://www.terraform.io/docs/providers/aws/
Is there a way to set a heroku app as private?
I would like to deploy several internal services at heroku and make them only accessible between themselves. I would like to do it this way to hide the backend from the internet access and only allow a frontend app to be accessed by users from outside.
By default, practically everyone who can guess the correct heroku domain could access the backend and attack it directly.
Update:
To be more specific: I am looking for an altenative way besides Heroku private spaces
No, you cannot do this. What you should do if you need this functionality is to secure your web applications with a protocol like HTTP Basic Auth, or OAuth2 Client Credentials. Either of these will allow you to securely authenticate requests BETWEEN your Heroku apps without leaking data publicly.
I was wondering how people are handling security aspects when using Spring Cloud Config.
I'm planning to use Spring Cloud Config Server and Client together with Spring Boot. From an implementation point of view this is quite straight, but how do you deal with the risk of disclosing password/access to every developer.
e.g. you run one central configserver containing configurations for all environment. In the bootstrap.yml of the config client app you'll have to configure the username/password to access the configserver. So far so good, but when I know commit the username/password in the respective yml file, then every developer has potential access to all environments by just switching the profile from e.g. development to production (please let's not start a discussion why not every developer needs access to production).
I'm aware that I can encrypt all passwords in the configuration, we do this, but that's not what I'm looking for. Encryption is just a feature to not have the passwords being stored plaintext in the files, but the user does not really need to know the plain password to get access if he has access to the configserver in the first place.
This is also about avoiding mistakes during development... its just to easy to switch the local environment to connect to production or any other environment.
So how are people dealing with this? Do you inject a different bootstrap.yml in development then in other environments? if so how do you administrate/propagate these?
Do you set the password for the configuration user on the comandline?
...?
We use variables and default values for config server URL, user and password
${config_username:user}:${config_password:password}#${config_server:conf.mydomain.com}
Default values can be valid credentials for development environment this way you simply run it while you develop. When you deploy to production simply set those environment variables and your application will connect to a different config server
I was thinking about this myself and came up with 3 options. In all cases, use {cipher} values in repos for sensitive data and disable various actuator endpoints that would allow decryption or property value lists.
Have two config servers, one for dev and one for prod, with no dev access to the prod server, controlled by credentials provided to the prod client at runtime.
Perform the decryption client side, using a secret provided to the prod client at runtime.
Explicitly define a prod profile and block access to URLs containing that profile from non-prod servers.
What is the best way to send a password to a Windows Service? Our application needs a password in order to start. I don't care that services are "normally" supposed to run without user interaction. Its good enough for us that an operator can start the application and then log off.
On a unix system, I would just echo the password over stdin but the service has no stdin.
Currently, we use the DPAPI to just store the password using CryptProtectData. While this, works, it presents other problems that are beginning to become troublesome.
I'm guessing that I'll need to use some form of IPC between the service and the application that is sending the password but I'm not sure which method is appropriate, if any.
Thanks
Two main options:
You could listen on a socket on startup and wait for the required password to be supplied (maybe embed an SSH server in there, so that the password cannot be snooped over the wire)
My preferred option would be to read the password from a configuration file (that can be secured to the minimum readership) or registry setting (again, sufficiently secure such that only your service and administrators can read/change it)
Thanks for responding Rowland.
You could listen on a socket on
startup and wait for the required
password to be supplied (maybe embed
an SSH server in there, so that the
password cannot be snooped over the
wire)
I considered that but without certificate verification, wouldn't that leave us open to a man in the middle attack?
My preferred option would be to read
the password from a configuration file
(that can be secured to the minimum
readership) or registry setting
(again, sufficiently secure such that
only your service and administrators
can read/change it)
We're trying to follow "defense in depth" as much as possible such that if an attacker compromised the machine, he would not able to access our application.
You can use kerberos mutual authentication. There are few options and examples there.
But just wondering. On a compromised machine, There may be a key logger. So typing the password is never secure if you want to maintain security in this environment. The same problem exist afaik for unix terminals.
DPAPI in UserMode is really the best option, and storing the encrypted data in a protected location, e.g. registry key with limited ACL.
What exactly were the problems that are beginning to be troublesome? Maybe we can just solve those...
What exactly were the problems that
are beginning to be troublesome? Maybe
we can just solve those...
Currently, the application runs as the Local System account.
Our application stores a number of credentials in an encrypted file and uses the DPAPI (in UserMode) for the encryption.
Thus, when the application is installed, the installer is run as the Local System account. We also have a set of tools that ship with the application, some of which need access to this encrypted file and thus, they too need to run as the Local System account.
By the time the application is installed and started, we're heavily dependent on that account.
We're running into problems because one of our users wants to use the application to access a shared network drive. The Local System account has no such privileges and we can't simply run our service as a different user because our encrypted information is protected under the Local System Account.
We've tried to avoid the process of setting up a user account just for our application because it is installed across many different customers and environments, all of whom have wildly different security policies.
You can access a remote drive from a service running under system account. However, you will need to have credentials & share information to connect to the remote machine. You can use the API wnetaddconnection to gain access. Probably your encrypted file can store this credential as well.