I have an app that I want to run in Cloud Foundry (specifically, in IBM Bluemix). This app will call out to a number of third-party services/APIs, most of which are not managed via CF services. One of these APIs requires my app to use an SSL key to authenticate, so my app needs access to a private SSL key.
My app is deployed from an automated pipeline (specifically, IBM Bluemix DevOps Pipelines) based off of source from a GitHub repo and some small scripts saved in the pipeline config.
It seems like a bad idea to keep the private key file in the source control, and I don't believe there's anywhere to keep it in the pipeline config, so what are my options for making it available to the app while keeping it secure?
I've read this article: Keeping secrets – how your cloud application should access credentials and other private data which says that secrets, passwords, etc, can be made available via environment variables or Cloud Foundry user-provided services.
Googling to find out if this is a suitable option for SSL keys, I find this Cloud Foundry Page: Understanding Cloud Foundry Security which says "Store SSL keys securely to prevent disclosure, and promptly replace lost or compromised keys.", but doesn't say anything about how to store them securely and make them available to your apps.
So what options are available to me for storing the private key and making it available to my CF app while not storing it in my source control?
Note: I believe I do not want the cf ssh functionality, as that is for connecting in to an app (if I understand it correctly), not for an app connecting out.
Agreed - keeping your key in source control is bad practice.
Bluemix has a service called Key Protect that should provide exactly what you're looking for.
Docs here
Alternatively there are a number of other 3rd party providers you could use to do this.
Related
I am working on a .NET core console application which integrates with 3rd party APIs. and to do the integration I need to pass the API keys inside the API requests. so my question is where/how I can store the API keys inside my console application? in regular .NET console application I use to store the API keys inside the app.config and encrypt the keys using Aspnet_regiis.. but not sure how i can do so inside .NET core console application?
You can consider...
Get separate keys issued for different environments (so that a compromised key can be expired/cancelled without affecting other environment/s).
Store keys encrypted - for example - in the operating system provided key store [https://learn.microsoft.com/en-us/dotnet/standard/security/cryptography-model]. (This just means that they are not "left lying around" for casual passers by.)
Remove the code for retrieval of keys from the console app, perhaps to a simple service or library to which code the regular developers do not have access. (A level of separation.)
To embed information within the application, consider resource files [https://learn.microsoft.com/en-us/dotnet/framework/resources/creating-resource-files-for-desktop-apps]
Bottom line: This question illustrates the raison d'être for public key (asymmetric) cryptography [https://en.wikipedia.org/wiki/Public-key_cryptography] but any app that handles a piece of information "decrypted in flow" makes that information vulnerable to everyone who has permission to work on (debug) the live app or poke around with diagnostic tools on the system. (If a person needs a key to open a door then you must give them a key with which to open it and can't then prevent dishonest misuse of that privilege.)
A little bit of paranoia is healthy but too much can be an obstacle to getting things done.
Security in Development
For local development, you can use the Secrets Manager Tool (used only in development, never in production). This tool allows you to store your sensitive data locally on your machine, outside the project tree.
This tool is not super secure, and the keys are not encrypted, but it provides an easy way to avoid storing secrets in your project config files and having to remember to add them to the source control ignore list.
Security in Production
A common way is to store secrets in an external vault.
If you are hosting your application on Azure, Azure also provides a more secure option: Azure Key Vault.
Key Vault is a cloud-hosted service for managing secrets, which will be accessible by the applications you authorize through an encrypted channel.
It is advisable not to store encrypted keys inside a .NET console application. It is more ideal to keep secrets separate, store them using the Secret management tool in dev mode, and look into services like Azure KeyVault for production as mentioned earlier.
See the link about app secrets and configuration and why we need a tool to manage it on https://dev.to/dotnet/how-to-store-app-secrets-for-your-asp-net-core-project-2j5b for detailed instructions on how to do this.
I had a talk with a friend today about a project his startup is doing. It is a nodejs application with a mongodb backend hosted on Google Cloud App Engine. To my horror I saw that he has stored secrets such as API keys and database keys in his git repo.
I come from an Azure and .NET background so I am used to using Azure Key Vault, and don't know what is the preferred way of doing it in GAE. I have tried to read the docs but there are a lot of options and none seems to quite mirror what I am used to in Azure.
I would like to help my friend out.
So could anyone please point me towards what product I should read up on. Is it Hashicorp Vault, Google Cloud HMS or Berglas? My needs are that the vault needs to be able to store secrets encrypted and the nodejs app should not need to worry about authenticating with the vault. The vault should just allow the service account to read secrets.
If the vault can also fit into a Terraform setup where we can provision all resources and at provisioning also generate the secrets needed and then put them into the vault without any human ever laying eyes on that secret, then that would be really awesome! That way we could also create a setup where he would be able to provision a full disposable environment based on a feature branch. But that is just a nice to have.
Based on the fact that you want to use Terraform as well, I would suggest using HashiCorp. There is a blog post about the combination of those 2 from Google. In general, all those solutions that you mentioned in your question are viable and you can find more here.
I am trying to encrypt the connection strings of the web app hosted in azure. I found that this can be done using the aspnet_regiis.exe tool. But, my question is we have the auto scale out enabled and it happens quite often. So, If I encrypt the connection strings using the tool mentioned above, will it work if the webapp is scaled out. Is there any other way to encrypt?
If you want to securely store your connection string you should use Azure Key Vault (as mentioned by Peter Bons).
To safely access the credentials you should consider using Managed Identities.
Here is the Managed Identities documentation for App Services
I am trying to deploy the Spring Cloud Data Flow Server to an enterprise Pivotal Cloud Foundry instance using an application manifest.yml.
My first concern is externalizing the SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_USERNAME and SPRING_CLOUD_DEPLOYER_CLOUDFOUNDRY_PASSWORD properties from the manifest so I'm not storing them in plain text in version control. Is there a best practice to accomplish that? Where does that fit into the workflow of deploying a Data Flow Server and associated Streams/Tasks? My initial idea is to create a new Cloud Foundry user for the Data Flow Server that can deploy applications to the org/space I am using, then potentially use Spring Cloud Config to inject the credentials into the env. Is that a typical solution?
My second concern is requiring TLS/HTTPS for all of the Data Flow Server's web endpoints. I again attempted to omit the properties concerning the key store locations from the manifest in the SPRING_APPLICATION_JSON env entry, but that again caused initialization to fail. Does the Cloud Foundry Java buildpack have a standard location for those certificate stores, or is that specific to my Cloud Foundry instance? I also want to redirect all HTTP requests to HTTPS? Do I need to create a custom build of the Cloud Foundry Data Flow Server to do that?
Thanks for any help.
UPDATE:
Based on other SO posts, I have now resolved that I do not need to enable HTTPS/TLS from the Data Flow Server config in its embedded Tomcat server because it is sitting behind Cloud Foundry's proxy. However, I cannot see a way to require and redirect to HTTPS endpoints other than creating a customized build of the Data Flow Server for Cloud Foundry with the proper configuration.
You can refer the documentation for this here.
The Security section from the docs linked in the previous answer should be useful. I'll attempt to reply few specific questions.
I'm not storing them in plain text in version control
A few of our customers use Config-Server + Vault integration for encrypted password credentials.
My initial idea is to create a new Cloud Foundry user for the Data Flow Server that can deploy applications to the org/space I am using, then potentially use Spring Cloud Config to inject the credentials into the env. Is that a typical solution?
This whole experience will be automated with e2e OAuth/SSO workflow with Spring Cloud Data Flow's tile, which will be available as a BETA tile by this month. There won't be any clear-text passwords - everything will be OAuth token driven, and the service-broker will control the lifecycle of SCDF's service-instance. Please reach out to PCF account rep and we would gladly add you to the BETA program.
I'm starting to develop an application using node.js on azure. I'm using everyauth to provide authentication because I want to support lots of different authentication methods. I plan to deploy to Azure. The potential problem I have is that everyauth requires the connect.session helper. Will this work with azure when running multiple instances? Or do I need an alternative session provider?
I have never used Node.js on Azure, but:
everyauth
Looking at the documentation for everyauth there is a method for authenticating against a Windows Azure ACS. See the section entitled Setting up Windows Azure Access Control Service (ACS) Auth in the readme for more information. There are no notes there about it not working on Azure itself so I would infer from that that you can use it on Azure.
connect-azure
There is also a project called connect-azure, which appears to be using connect.session so again I would extrapolate from this that it will work on Azure.
Contact Azure support
If you are already a customer you can contact support for help.
Try it and see
So if you have the Azure environment setup I would definitely say it is worth trying it out.
This was asked a while ago, but I thought I would attempt an answer anyway. It seems that connect-session relies on cookies to maintain the session. Azure has a different load-balancing strategy depending on what you use:
WebRole/WorkerRole - the LB doesn't have any affinity so requests from your clients might end up at different backend instances. This will throw off whatever session management connect is doing. This is a side effect of a distributed cloud architecture: you don't want any backend node to be the source of truth since it can go down. So what you would have to do is figure out how to externalize connect's cookie store and have all backends share it. This way no matter what backend receives the request, it will be aware of the session.
Websites - in this case the LB will actually try to pin a client connection to a given backend instance, so cookie-based sessions may work without any changes. You are sacrificing failover, as described above.