I’m using a hosting website to host my discord bot and my .env stores the token. How does it still work when the file is .gitignored? Because I don’t want people stealing my token and using it for other purposes.
Your initial deployment process on your hosting needs to be more complex than "Pull the application from my Git repository".
For simple applications that generally just means you create the .env file on the hosting manually.
For complex systems (e.g. when you have multiple instances of the application on different servers) you'll generate it from a secure data store as part of a process that involves a deployment tool like Terraform.
You use gitignore and add the .env extension in it to make sure that it does not get pushed to the remote repository on github so that no-one can access those variables. in order to add the .env variables on a hosting website, you need to add the environment variables externally on that hosting site. The method depends entirely on the service provider.
Related
Current Situation:
I have a server running a NestJS using .env file to handle environment variables (including secrets). I use GitHub Actions to do the whole CI flow, storing the secret values in the GitHub Actions Secrets. When pushing the commits, CI Server will create the .env file (write secrets in it) and build the service, then rsync over ssh to the production server.
But I am thinking of if my server is being hacked, the attacker will be able to see my .env file and know all the secrets. Then I studied a bit about secret management tools, it seems that I have to install their SDK and get the secret, but I think it is bad because I don't want to bind a specific secret manager in my code.
So my question is
Is using a secret manager more secure than .env file because it loads the secrets from the manager to the memory directly instead of having a middleware (the .env file) to store the secrets?
If 1 is yes, then am I achieving the same security level if I delete the .env file after loading the service?
How about just setting the .env file permission to 600 root:root? Is finding secrets in memory commonly harder than privilege escalation?
(Extra) Is there any potential security issue in my CI flow?
Thanks
I have an application written in Node.js that I am deploying to the IBM Cloud infrastructure. Everything works great as long as I have the environment variables for the app embedded in my manifest.yml file. This isn't ideal since it keeps these secure values within my GitHub repository.
I use a .env file for my local testing and placing that in my .gitignore is great to ensure that it doesn't roll out to the Git repo, but having to place the values into my manifest really defeats the purpose.
Is there a way to ensure that my environment variables are kept between CI runs that I store on my IBM Cloud apps without resorting to storing them in the manifest?
If you are using Cloud Foundry, then I would recommend to take a look at how Cloud Foundry integrates with services. It allows to bind a service to an app, thereby making the credentials available. If you already have some services, like another database, you can utilize the concept of user-provided service. There is no need to set variables, it is managed by Cloud Foundry.
Those concepts integrate well with the Continuous Delivery service on IBM Cloud.
where you run continuous integration? if you run on IBM Cloud Continuous Delivery you can set Environment Variable and provide access to your job to access it.
you can see the documentation in here.
I've created a .env file per the dotenv documentation and placed all my secret API keys inside the file. I've also added these environment variables as config variables to my Heroku instance. As a result, secret API strings are no longer referenced in my source code.
However, I haven't gitignored the .env file since the git repo is set to private and I'm the sole owner of it but I have slugignored the .env file to stop it from being pushed into Heroku.
Is my justification to not gitignore the .env file safe and are the steps I'm taking reasonable and standard practice to protect my secret API strings? If not, how else can I improve upon my setup to improve the security of my web app?
Are the creds in .env the same ones you have on your heroku app?
If so, this is bad.
Someone getting access to your GitHub account could also access the creds in your Heroku app. Look at this Gentoo retrospective where getting their GitHub organization compromised is exactly what happened.
Your .env file should only have local settings. For example, it should call localhost as the database, not your production database URL.
Then, once everything is decoupled from production, this file can safely be checked into your repository. Someone getting access to your code wouldn't be getting any access to your production data.
Take the following case as example.
You've a RESTful API layer secured using OAuth2. In the other hand, to let users authenticate against your APIs, you need to request an access token (i.e. grant_type=password).
In order to request a password access token, client app requires an OAuth Client (key+secret pair).
Now you've configured everything to use continuous integration and continuous deployment.
During a development build, the build script creates test data, including OAuth clients. Obviously, if a build creates test data, it previously drops all data created during automated tests.
So you'll want your client app to use one of OAuth clients and you want to avoid hardcoding one of them, because they're created using the API infrastructure, so they're re-created from scratch on each build.
Think that front-end and back-end are built by different build scripts.
Conclusion & question
What would be a good approach to share secrets between the server and client infrastructure, so both get up and running synchronized with the same security secrets?
Some ideas
Operating system environment variables. I could store those secrets on build machine environment variables. That is, client infrastructure will be always built and deployed with most up-to-date secrets.
Same as #1, but storing those secrets on a shared directory in the build machine.
Regarding TFS/VSTS build (TFS 2015 or later)/release (TFS 2017 or VSTS) system, you just need to check Allow Scripts to Access OAuth Token option in Options/General tab of build definition or release environment, then you can fetch Access OAuth Token by using $(System.AccessToekn) in each task.
Regarding other system, the better approach is to store the access token in system environment variables and remove it at the end, which is similar to the share variable value for other build/release tasks by using "##vso[task.setvariable variable=testvar;]testvalue" (PowerShell) in TFS or VSTS.
On the other hand, you can store encrypted Access Token in system environment for security, then decrypt and use it.
Finally I've ended up with the common build directory to store a JSON file with latest credentials approach where both builds can access it. Each backend build run persists a JSON file containing the whole credentials, and frontend build relies on the whole file.
Anyway, I tried the environment variables' approach, but since both builds are running on the same TFS build agent, client build couldn't see environment variables' changes unless the whole agent service would be restarted.
Is there a way with Kudu (or some other means) to retrieve the MySql connection information when I push with Git?
I know I can access it through the portal, but I want to write a build script that generates some files based on the Azure Web Site I'm going to push to. I also am aware of the App Settings, but I don't want duplication there.
I'm deploying a custom built WordPress instance where I want to build the wp-config.php file dynamically and not have it checked in to my repository.
Yes, your connection string is available as an environment setting.
To experiment with custom scripts use kuduexec (http://blog.amitapple.com/post/45675601255/azurewebsiteterminal)