I know the question is very broad / vague. But what would be the best way to secure the .boto config file?
If I encrypt the file, how will boto know how to decrypt it again? Or does boto provide some other way for securing the config file?
Any suggestions / links would be helpful. Thanks.
If you are using boto on EC2 instances, use IAM Roles to get temporary credentials onto your instances. These temporary credentials are rotated frequently and can be scoped to provide only the access necessary for your programs to do their jobs.
If IAM Roles don't work for you, you can also use keyring to securely store credentials in a boto config file. You can find some simple instructions here. You will need to install keyring on your computer in order to allow boto to take advantage of it.
Related
in the cloud functions is better use firebase config command and then use (for example ; functions.config().stripe.secret_key ) or Google Secret Manager ? From the documentation I can't tell, I only understood that the only thing not to use is the local env and that firebase functions config is actually server-side, so nothing is exposed.
In addition to #John Hanley's comment, storing environment variables in .env files is not recommended as it is not a secure way to store sensitive information such as API keys, credentials, passwords, certificates, and other sensitive data that could be decoded.
Environment variables stored in .env files can be used for function configuration, but you should not consider them a secure way to store sensitive information such as database credentials or API keys. This is especially important if you check your .env files into source control.
To help you store sensitive configuration information, Cloud Functions for Firebase integrates with Google Cloud Secret Manager. This encrypted service stores configuration values securely, while still allowing easy access from your functions when needed.
It is recommended to create and use a secret manager to secure your sensitive information. You can check this documentation on configuring your environment and storing and accessing sensitive configuration information for Firebase.
You can check this documentation on Secret Manager for more details on how to manage and secure your secret.
For our product we have decided to implement a Secret Management tool (AWS secrets manager) that will securely store and manage all our secrets such as DB credentials, passwords and API keys etc.
In this way the secrets are not stored in code, database or anywhere in the application. We have to provide the AWS credentials - Access Key Id and Secret access key to programmatically access the APIs of Secrets manager.
Now the biggest question that arises is, where to keep this Initial Trust – the credentials to authenticate the AWS secrets manager.? This is a bootstrapping problem. Again, we have to maintain something outside of the secret store, in a configuration file or somewhere. I feel If this is compromised then there is no real meaning to store everything in a Secret management tool.
I read the AWS SDK developer guide and understand that there are some standard ways to store AWS credentials like – storing them in environmental variables, credentials file with different profiles and by Using IAM roles for Amazon EC2 Instances.
We don’t run/host our application in Amazon cloud, we just want to use AWS secrets manger service from AWS cloud. Hence, configuring the IAM roles might not be the solution for us.
Are there any best practices (or) a best place to keep the initial Trust credentials?
If you're accessing secrets from EC2 instance, ECS docker container, Lambda function, you can use Roles with policy that allows access to Secrets Manager.
if IAM Role is not an option, You can use Federation Login to get temporary credentials (IAM Role) with policy that allows access to Secrets Manager.
As #Tomasz Breś said, you can use federation if you are already using an on-premis Auth system like Active directory or Kerberos.
If you do not have any type of credentials already on the box, you are left with two choices: store your creds in a file and use file system permissions to protect them, or use hardware like an HSM or TPM to encrypt or store your creds.
In any case, when you store creds on the box (even AD/Kerberos), you should ensure only the application owner has access to that box (in the case of a stand alone app and not a shared CLI). You should also harden the box by turning off all un-necessary software and access methods.
We're using Vault to store our application secrets and config. When our app (Java) starts, a script does all the magic of getting the secrets and config from Vault and storing them locally for the application to read. The script is authenticating to Vault using AWS IAM role.
Now we're getting to a situation where the application needs to read secrets from Vault on the go, not just on startup. For that purpose, I need it to be able to do the authentication pretty much on every request. It's worth mentioning that the app might also run on the developer machine, so whatever authentication done - it needs to work on the EC2 instance as well as the local development environment.
I'm currently leaning towards creating a username and password, store them in Vault for the application to get when starting up. Then the application could use that username/password to authenticate to Vault when it needs.
I'm also considering AppRole, but can't really see any real advantage to it over simple user/password setup.
What's the best solution for this use-case? Any advise would be highly appreciated!
Thanks,
Yosi
The AWS recommendation for storing secrets is to use AWS Systems Manager Parameter Store.
Software running on an Amazon EC2 instance with an assigned Role can use those credentials to access the Parameter Store to retrieve application secrets.
The Parameter Store can also be used outside of EC2, but some AWS credentials will still be needed to authenticate to the Parameter Store.
Is there a way to apply Apache server config (in httpd.conf) to Openshift PHP application? I need to add a configuration so that Apache acts as reverse proxy for specific URL pattern and those requests need to be handled by a java application also hosted in Openshift. But I do not have access to httpd.conf file and only root user has access to it. The file I am referring to is (php/configuration/etc/conf/httpd.conf)
The users do not have permissions to edit the hhtpd.conf file in PHP cartridges I know of.
However, you can develop your own cartridge, that will have it configured according to your needs. You can find more about creating cartridges here.
I'm working on an application in VB.NET that has to connect to a MySQL database and FTP. How secure is it if I used it in an application that I gave to other people. E.g. if I was to let other people use this application would they be able to find out the MySQL and FTP connection details through intercepting packets or something like that?
If that's the case how can I work round this? Also, part of my application is an uploader for users to upload files, is FTP secure for that or are there better alternatives ways in doing that? My server is a Windows Server 08 if that makes any difference.
Thanks in advance.
FTP is plaintext. It is very easy to get user names and passwords just by packet sniffing. If the ftp is supposed to be secure rather look ay sftp or ftps solutions. These use SSL type encryption on the network layer. Never ever use a ftp server for sensitive information.
MySQL traffic can also be sniffed though it is considerably harder to reverse engineer the protocol. If data has to flow between client and mysql in a secured fashion you can configure mysql to use SSL certificates to encrypt the information. This will ensure security is of highest standards.
It depends, but as per Accessing SQL Server with Explicit Credentials article and it is applicable to MySql as well:
The recommended method is to store the predetermined user name and
password on the server, and then read it and add it to the connection
string at run time. An advantage of this technique is that your
application can access the database using different credentials under
different circumstances, depending on what it needs to do in the
database.
Security Note Never hard-code credentials as strings into programs in your application. Anyone who can get access to the code
file, even the compiled code, will be able to get at the credentials.
Security Note Always give a predetermined user name the minimal access privileges to a resource. Never use "sa" or any other
administrative-level user name. Always use passwords