How can I not push my API Keys/Credentials to Github, especially Public Repos
up vote
8
down vote
favorite
I did ask a few devs on how do they ensure that keys and credentials files aren't pushed. They did give me few answers, but I didn't find anything consistent.
Lets say there is a creds.json file in /config folder. What are the efficient ways to NOT push these credentials to Github.
Few of the answers I found online :
- Add them to .gitignore
- Store keys separately inside the host machine or different folder
- Just be cautious
Blogs I read :
https://www.agwa.name/projects/git-crypt/
https://blog.roundingpegs.com/how-i-avoid-committing-passwords-to-github/
Is there any tool or a more efficient way such that I don't commit my keys accidentally to Github or warn me before I commit?
I would like you to give a summary of all the possible ways in which you can prevent keys from going to github. Examples to support your summary would be great.
git github
add a comment |
up vote
8
down vote
favorite
I did ask a few devs on how do they ensure that keys and credentials files aren't pushed. They did give me few answers, but I didn't find anything consistent.
Lets say there is a creds.json file in /config folder. What are the efficient ways to NOT push these credentials to Github.
Few of the answers I found online :
- Add them to .gitignore
- Store keys separately inside the host machine or different folder
- Just be cautious
Blogs I read :
https://www.agwa.name/projects/git-crypt/
https://blog.roundingpegs.com/how-i-avoid-committing-passwords-to-github/
Is there any tool or a more efficient way such that I don't commit my keys accidentally to Github or warn me before I commit?
I would like you to give a summary of all the possible ways in which you can prevent keys from going to github. Examples to support your summary would be great.
git github
And don't forget the "damage control": git-scm.com/docs/git-filter-branch >git-filter-branchallows you to make complex shell-scripted rewrites of your Git history, but you probably don’t need this flexibility if you’re simply removing unwanted data like large files or passwords.
– Emil Vatai
Nov 11 at 8:18
The examples saygit filter-branch --tree-filter 'rm filename' HEADwould be the command to use.
– Emil Vatai
Nov 11 at 8:25
add a comment |
up vote
8
down vote
favorite
up vote
8
down vote
favorite
I did ask a few devs on how do they ensure that keys and credentials files aren't pushed. They did give me few answers, but I didn't find anything consistent.
Lets say there is a creds.json file in /config folder. What are the efficient ways to NOT push these credentials to Github.
Few of the answers I found online :
- Add them to .gitignore
- Store keys separately inside the host machine or different folder
- Just be cautious
Blogs I read :
https://www.agwa.name/projects/git-crypt/
https://blog.roundingpegs.com/how-i-avoid-committing-passwords-to-github/
Is there any tool or a more efficient way such that I don't commit my keys accidentally to Github or warn me before I commit?
I would like you to give a summary of all the possible ways in which you can prevent keys from going to github. Examples to support your summary would be great.
git github
I did ask a few devs on how do they ensure that keys and credentials files aren't pushed. They did give me few answers, but I didn't find anything consistent.
Lets say there is a creds.json file in /config folder. What are the efficient ways to NOT push these credentials to Github.
Few of the answers I found online :
- Add them to .gitignore
- Store keys separately inside the host machine or different folder
- Just be cautious
Blogs I read :
https://www.agwa.name/projects/git-crypt/
https://blog.roundingpegs.com/how-i-avoid-committing-passwords-to-github/
Is there any tool or a more efficient way such that I don't commit my keys accidentally to Github or warn me before I commit?
I would like you to give a summary of all the possible ways in which you can prevent keys from going to github. Examples to support your summary would be great.
git github
git github
edited Nov 12 at 3:52
asked Nov 7 at 11:31
DeathJack2.0
679221
679221
And don't forget the "damage control": git-scm.com/docs/git-filter-branch >git-filter-branchallows you to make complex shell-scripted rewrites of your Git history, but you probably don’t need this flexibility if you’re simply removing unwanted data like large files or passwords.
– Emil Vatai
Nov 11 at 8:18
The examples saygit filter-branch --tree-filter 'rm filename' HEADwould be the command to use.
– Emil Vatai
Nov 11 at 8:25
add a comment |
And don't forget the "damage control": git-scm.com/docs/git-filter-branch >git-filter-branchallows you to make complex shell-scripted rewrites of your Git history, but you probably don’t need this flexibility if you’re simply removing unwanted data like large files or passwords.
– Emil Vatai
Nov 11 at 8:18
The examples saygit filter-branch --tree-filter 'rm filename' HEADwould be the command to use.
– Emil Vatai
Nov 11 at 8:25
And don't forget the "damage control": git-scm.com/docs/git-filter-branch >
git-filter-branch allows you to make complex shell-scripted rewrites of your Git history, but you probably don’t need this flexibility if you’re simply removing unwanted data like large files or passwords.– Emil Vatai
Nov 11 at 8:18
And don't forget the "damage control": git-scm.com/docs/git-filter-branch >
git-filter-branch allows you to make complex shell-scripted rewrites of your Git history, but you probably don’t need this flexibility if you’re simply removing unwanted data like large files or passwords.– Emil Vatai
Nov 11 at 8:18
The examples say
git filter-branch --tree-filter 'rm filename' HEAD would be the command to use.– Emil Vatai
Nov 11 at 8:25
The examples say
git filter-branch --tree-filter 'rm filename' HEAD would be the command to use.– Emil Vatai
Nov 11 at 8:25
add a comment |
5 Answers
5
active
oldest
votes
up vote
5
down vote
I prefer storing them separately inside the host machine or a different folder and use them over an environment variable. Like that you have you cannot commit them accidentally.
Additionally you can use them in CI build. If you also need credential in CI build most systems provide encrypted variables which are stored encrypted on the build server and can be used as environment variables.
Like that I can use also different credentials for each local user or CI without changes in my code.
Environment Variable as in Jenkins?
– DeathJack2.0
Nov 7 at 11:44
Environment variables as in every operating system. Here some sample usages for Travis or Jenkins
– FreshD
Nov 7 at 11:49
add a comment |
up vote
3
down vote
Of course there is a a better way!
I would suggest you not to store any passwords hard coded in your code because of the risks of it being uploaded to Github or any other public repositories. The better way to do it is to have a keyring/application that can store your passwords in cloud and make them accessible to your application only.
For example, AWS Secrets Manager. I am sure there are other applications that can do so but this is the one I would recommend. With this tool, you can manage your passwords, rotate your passwords and API keys without being worried about the keys getting uploaded to the public repo's. After storing it here, you need to have a secret manager in your code that will fetch the password and use it in the application.
Also these are some of the other options:
- Keeping API Key's in database and loading it from there
- .ini file or .conf file or .env file which are kept in /etc folders
- AWS Secrets Manager, of course
I also found promising answers here: https://medium.com/slalom-technology/secret-management-architectures-finding-the-balance-between-security-and-complexity-9e56f2078e54
And how do you make these things "accessible to your application only"? Surely in a way that can easily be spoofed, no?
– rubenvb
Nov 7 at 13:31
If you're using an AWS EC2 instance then it will be accessible to your instance only. But if you want to use it in some external machine, then you might need to make requests to secret manager and get your keys. To access secret manager you will need another key, which should be kept in database or outside your code base like conf file.
– theBuzzyCoder
Nov 7 at 13:37
Exactly what I thought, if the client needs to directly query an API with a key, this type of solution doesn't apply. Thanks for confirming!
– rubenvb
Nov 7 at 15:05
add a comment |
up vote
0
down vote
It looks like git-secrets does exactly what you are asking for.
add a comment |
up vote
0
down vote
You can have a separate project / package that contains your environment specific configuration, including your secrets.
The secrets are encrypted with a private key, that only authorized persons would have.
When installing your package, you will need the private key to decrypt the secrets on te target machine, that could be done by a ops /dev-ops with access to the private key.
In that way, you can safely push your encrypted secrets to github or any insecured environment.
Alternatively, you can look at https://www.agwa.name/projects/git-crypt/ that allows you to have encrypted files, but I still prefer to have a separate package for the secrets, as you would need different secrets per environment (UAT, prod etc).
Or you could encrypt your whole repo https://github.com/spwhitton/git-remote-gcrypt but you would lose your hosted environment features such as browse commit history etc.
add a comment |
up vote
0
down vote
You can use some industry standard tools like Hashicorp's vault "https://www.vaultproject.io/" to store the secrets and retrieve them when required. Lot of big gaints use this tool to manage their secrets. You have to install vault in your organization's environment to access vault. You can refer to this article
"https://www.digitalocean.com/community/tutorials/how-to-securely-manage-secrets-with-hashicorp-vault-on-ubuntu-16-04" on how to install and access secrets from vault. It is PCI complaint and can be used to store very sensitive information. Fortunately there is a library from spring which you can use to easily read secrets from vault. Refer this page for sample code and more "https://projects.spring.io/spring-vault/".
On the other hand there is an offering from Amazon web services called secrets manager. If you organization is using AWS and your apps are hosted in AWS environment it is quite easy for you to put secrets in secret's manager and access them. But secrets manager is not PCI complaint yet and is expected to be PCI complaint in the next upcoming months. Please refer to this video "https://www.youtube.com/watch?v=HiY2oxR1Jd0" on how to use secret's manager in your application.
Hope this helps you. Cheers !!
add a comment |
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
I prefer storing them separately inside the host machine or a different folder and use them over an environment variable. Like that you have you cannot commit them accidentally.
Additionally you can use them in CI build. If you also need credential in CI build most systems provide encrypted variables which are stored encrypted on the build server and can be used as environment variables.
Like that I can use also different credentials for each local user or CI without changes in my code.
Environment Variable as in Jenkins?
– DeathJack2.0
Nov 7 at 11:44
Environment variables as in every operating system. Here some sample usages for Travis or Jenkins
– FreshD
Nov 7 at 11:49
add a comment |
up vote
5
down vote
I prefer storing them separately inside the host machine or a different folder and use them over an environment variable. Like that you have you cannot commit them accidentally.
Additionally you can use them in CI build. If you also need credential in CI build most systems provide encrypted variables which are stored encrypted on the build server and can be used as environment variables.
Like that I can use also different credentials for each local user or CI without changes in my code.
Environment Variable as in Jenkins?
– DeathJack2.0
Nov 7 at 11:44
Environment variables as in every operating system. Here some sample usages for Travis or Jenkins
– FreshD
Nov 7 at 11:49
add a comment |
up vote
5
down vote
up vote
5
down vote
I prefer storing them separately inside the host machine or a different folder and use them over an environment variable. Like that you have you cannot commit them accidentally.
Additionally you can use them in CI build. If you also need credential in CI build most systems provide encrypted variables which are stored encrypted on the build server and can be used as environment variables.
Like that I can use also different credentials for each local user or CI without changes in my code.
I prefer storing them separately inside the host machine or a different folder and use them over an environment variable. Like that you have you cannot commit them accidentally.
Additionally you can use them in CI build. If you also need credential in CI build most systems provide encrypted variables which are stored encrypted on the build server and can be used as environment variables.
Like that I can use also different credentials for each local user or CI without changes in my code.
answered Nov 7 at 11:42
FreshD
1,18411224
1,18411224
Environment Variable as in Jenkins?
– DeathJack2.0
Nov 7 at 11:44
Environment variables as in every operating system. Here some sample usages for Travis or Jenkins
– FreshD
Nov 7 at 11:49
add a comment |
Environment Variable as in Jenkins?
– DeathJack2.0
Nov 7 at 11:44
Environment variables as in every operating system. Here some sample usages for Travis or Jenkins
– FreshD
Nov 7 at 11:49
Environment Variable as in Jenkins?
– DeathJack2.0
Nov 7 at 11:44
Environment Variable as in Jenkins?
– DeathJack2.0
Nov 7 at 11:44
Environment variables as in every operating system. Here some sample usages for Travis or Jenkins
– FreshD
Nov 7 at 11:49
Environment variables as in every operating system. Here some sample usages for Travis or Jenkins
– FreshD
Nov 7 at 11:49
add a comment |
up vote
3
down vote
Of course there is a a better way!
I would suggest you not to store any passwords hard coded in your code because of the risks of it being uploaded to Github or any other public repositories. The better way to do it is to have a keyring/application that can store your passwords in cloud and make them accessible to your application only.
For example, AWS Secrets Manager. I am sure there are other applications that can do so but this is the one I would recommend. With this tool, you can manage your passwords, rotate your passwords and API keys without being worried about the keys getting uploaded to the public repo's. After storing it here, you need to have a secret manager in your code that will fetch the password and use it in the application.
Also these are some of the other options:
- Keeping API Key's in database and loading it from there
- .ini file or .conf file or .env file which are kept in /etc folders
- AWS Secrets Manager, of course
I also found promising answers here: https://medium.com/slalom-technology/secret-management-architectures-finding-the-balance-between-security-and-complexity-9e56f2078e54
And how do you make these things "accessible to your application only"? Surely in a way that can easily be spoofed, no?
– rubenvb
Nov 7 at 13:31
If you're using an AWS EC2 instance then it will be accessible to your instance only. But if you want to use it in some external machine, then you might need to make requests to secret manager and get your keys. To access secret manager you will need another key, which should be kept in database or outside your code base like conf file.
– theBuzzyCoder
Nov 7 at 13:37
Exactly what I thought, if the client needs to directly query an API with a key, this type of solution doesn't apply. Thanks for confirming!
– rubenvb
Nov 7 at 15:05
add a comment |
up vote
3
down vote
Of course there is a a better way!
I would suggest you not to store any passwords hard coded in your code because of the risks of it being uploaded to Github or any other public repositories. The better way to do it is to have a keyring/application that can store your passwords in cloud and make them accessible to your application only.
For example, AWS Secrets Manager. I am sure there are other applications that can do so but this is the one I would recommend. With this tool, you can manage your passwords, rotate your passwords and API keys without being worried about the keys getting uploaded to the public repo's. After storing it here, you need to have a secret manager in your code that will fetch the password and use it in the application.
Also these are some of the other options:
- Keeping API Key's in database and loading it from there
- .ini file or .conf file or .env file which are kept in /etc folders
- AWS Secrets Manager, of course
I also found promising answers here: https://medium.com/slalom-technology/secret-management-architectures-finding-the-balance-between-security-and-complexity-9e56f2078e54
And how do you make these things "accessible to your application only"? Surely in a way that can easily be spoofed, no?
– rubenvb
Nov 7 at 13:31
If you're using an AWS EC2 instance then it will be accessible to your instance only. But if you want to use it in some external machine, then you might need to make requests to secret manager and get your keys. To access secret manager you will need another key, which should be kept in database or outside your code base like conf file.
– theBuzzyCoder
Nov 7 at 13:37
Exactly what I thought, if the client needs to directly query an API with a key, this type of solution doesn't apply. Thanks for confirming!
– rubenvb
Nov 7 at 15:05
add a comment |
up vote
3
down vote
up vote
3
down vote
Of course there is a a better way!
I would suggest you not to store any passwords hard coded in your code because of the risks of it being uploaded to Github or any other public repositories. The better way to do it is to have a keyring/application that can store your passwords in cloud and make them accessible to your application only.
For example, AWS Secrets Manager. I am sure there are other applications that can do so but this is the one I would recommend. With this tool, you can manage your passwords, rotate your passwords and API keys without being worried about the keys getting uploaded to the public repo's. After storing it here, you need to have a secret manager in your code that will fetch the password and use it in the application.
Also these are some of the other options:
- Keeping API Key's in database and loading it from there
- .ini file or .conf file or .env file which are kept in /etc folders
- AWS Secrets Manager, of course
I also found promising answers here: https://medium.com/slalom-technology/secret-management-architectures-finding-the-balance-between-security-and-complexity-9e56f2078e54
Of course there is a a better way!
I would suggest you not to store any passwords hard coded in your code because of the risks of it being uploaded to Github or any other public repositories. The better way to do it is to have a keyring/application that can store your passwords in cloud and make them accessible to your application only.
For example, AWS Secrets Manager. I am sure there are other applications that can do so but this is the one I would recommend. With this tool, you can manage your passwords, rotate your passwords and API keys without being worried about the keys getting uploaded to the public repo's. After storing it here, you need to have a secret manager in your code that will fetch the password and use it in the application.
Also these are some of the other options:
- Keeping API Key's in database and loading it from there
- .ini file or .conf file or .env file which are kept in /etc folders
- AWS Secrets Manager, of course
I also found promising answers here: https://medium.com/slalom-technology/secret-management-architectures-finding-the-balance-between-security-and-complexity-9e56f2078e54
edited Nov 7 at 13:26
answered Nov 7 at 11:49
theBuzzyCoder
8671116
8671116
And how do you make these things "accessible to your application only"? Surely in a way that can easily be spoofed, no?
– rubenvb
Nov 7 at 13:31
If you're using an AWS EC2 instance then it will be accessible to your instance only. But if you want to use it in some external machine, then you might need to make requests to secret manager and get your keys. To access secret manager you will need another key, which should be kept in database or outside your code base like conf file.
– theBuzzyCoder
Nov 7 at 13:37
Exactly what I thought, if the client needs to directly query an API with a key, this type of solution doesn't apply. Thanks for confirming!
– rubenvb
Nov 7 at 15:05
add a comment |
And how do you make these things "accessible to your application only"? Surely in a way that can easily be spoofed, no?
– rubenvb
Nov 7 at 13:31
If you're using an AWS EC2 instance then it will be accessible to your instance only. But if you want to use it in some external machine, then you might need to make requests to secret manager and get your keys. To access secret manager you will need another key, which should be kept in database or outside your code base like conf file.
– theBuzzyCoder
Nov 7 at 13:37
Exactly what I thought, if the client needs to directly query an API with a key, this type of solution doesn't apply. Thanks for confirming!
– rubenvb
Nov 7 at 15:05
And how do you make these things "accessible to your application only"? Surely in a way that can easily be spoofed, no?
– rubenvb
Nov 7 at 13:31
And how do you make these things "accessible to your application only"? Surely in a way that can easily be spoofed, no?
– rubenvb
Nov 7 at 13:31
If you're using an AWS EC2 instance then it will be accessible to your instance only. But if you want to use it in some external machine, then you might need to make requests to secret manager and get your keys. To access secret manager you will need another key, which should be kept in database or outside your code base like conf file.
– theBuzzyCoder
Nov 7 at 13:37
If you're using an AWS EC2 instance then it will be accessible to your instance only. But if you want to use it in some external machine, then you might need to make requests to secret manager and get your keys. To access secret manager you will need another key, which should be kept in database or outside your code base like conf file.
– theBuzzyCoder
Nov 7 at 13:37
Exactly what I thought, if the client needs to directly query an API with a key, this type of solution doesn't apply. Thanks for confirming!
– rubenvb
Nov 7 at 15:05
Exactly what I thought, if the client needs to directly query an API with a key, this type of solution doesn't apply. Thanks for confirming!
– rubenvb
Nov 7 at 15:05
add a comment |
up vote
0
down vote
It looks like git-secrets does exactly what you are asking for.
add a comment |
up vote
0
down vote
It looks like git-secrets does exactly what you are asking for.
add a comment |
up vote
0
down vote
up vote
0
down vote
It looks like git-secrets does exactly what you are asking for.
It looks like git-secrets does exactly what you are asking for.
answered Nov 17 at 20:46
Illya Kysil
49425
49425
add a comment |
add a comment |
up vote
0
down vote
You can have a separate project / package that contains your environment specific configuration, including your secrets.
The secrets are encrypted with a private key, that only authorized persons would have.
When installing your package, you will need the private key to decrypt the secrets on te target machine, that could be done by a ops /dev-ops with access to the private key.
In that way, you can safely push your encrypted secrets to github or any insecured environment.
Alternatively, you can look at https://www.agwa.name/projects/git-crypt/ that allows you to have encrypted files, but I still prefer to have a separate package for the secrets, as you would need different secrets per environment (UAT, prod etc).
Or you could encrypt your whole repo https://github.com/spwhitton/git-remote-gcrypt but you would lose your hosted environment features such as browse commit history etc.
add a comment |
up vote
0
down vote
You can have a separate project / package that contains your environment specific configuration, including your secrets.
The secrets are encrypted with a private key, that only authorized persons would have.
When installing your package, you will need the private key to decrypt the secrets on te target machine, that could be done by a ops /dev-ops with access to the private key.
In that way, you can safely push your encrypted secrets to github or any insecured environment.
Alternatively, you can look at https://www.agwa.name/projects/git-crypt/ that allows you to have encrypted files, but I still prefer to have a separate package for the secrets, as you would need different secrets per environment (UAT, prod etc).
Or you could encrypt your whole repo https://github.com/spwhitton/git-remote-gcrypt but you would lose your hosted environment features such as browse commit history etc.
add a comment |
up vote
0
down vote
up vote
0
down vote
You can have a separate project / package that contains your environment specific configuration, including your secrets.
The secrets are encrypted with a private key, that only authorized persons would have.
When installing your package, you will need the private key to decrypt the secrets on te target machine, that could be done by a ops /dev-ops with access to the private key.
In that way, you can safely push your encrypted secrets to github or any insecured environment.
Alternatively, you can look at https://www.agwa.name/projects/git-crypt/ that allows you to have encrypted files, but I still prefer to have a separate package for the secrets, as you would need different secrets per environment (UAT, prod etc).
Or you could encrypt your whole repo https://github.com/spwhitton/git-remote-gcrypt but you would lose your hosted environment features such as browse commit history etc.
You can have a separate project / package that contains your environment specific configuration, including your secrets.
The secrets are encrypted with a private key, that only authorized persons would have.
When installing your package, you will need the private key to decrypt the secrets on te target machine, that could be done by a ops /dev-ops with access to the private key.
In that way, you can safely push your encrypted secrets to github or any insecured environment.
Alternatively, you can look at https://www.agwa.name/projects/git-crypt/ that allows you to have encrypted files, but I still prefer to have a separate package for the secrets, as you would need different secrets per environment (UAT, prod etc).
Or you could encrypt your whole repo https://github.com/spwhitton/git-remote-gcrypt but you would lose your hosted environment features such as browse commit history etc.
answered Nov 18 at 5:44
Guillaume
9331624
9331624
add a comment |
add a comment |
up vote
0
down vote
You can use some industry standard tools like Hashicorp's vault "https://www.vaultproject.io/" to store the secrets and retrieve them when required. Lot of big gaints use this tool to manage their secrets. You have to install vault in your organization's environment to access vault. You can refer to this article
"https://www.digitalocean.com/community/tutorials/how-to-securely-manage-secrets-with-hashicorp-vault-on-ubuntu-16-04" on how to install and access secrets from vault. It is PCI complaint and can be used to store very sensitive information. Fortunately there is a library from spring which you can use to easily read secrets from vault. Refer this page for sample code and more "https://projects.spring.io/spring-vault/".
On the other hand there is an offering from Amazon web services called secrets manager. If you organization is using AWS and your apps are hosted in AWS environment it is quite easy for you to put secrets in secret's manager and access them. But secrets manager is not PCI complaint yet and is expected to be PCI complaint in the next upcoming months. Please refer to this video "https://www.youtube.com/watch?v=HiY2oxR1Jd0" on how to use secret's manager in your application.
Hope this helps you. Cheers !!
add a comment |
up vote
0
down vote
You can use some industry standard tools like Hashicorp's vault "https://www.vaultproject.io/" to store the secrets and retrieve them when required. Lot of big gaints use this tool to manage their secrets. You have to install vault in your organization's environment to access vault. You can refer to this article
"https://www.digitalocean.com/community/tutorials/how-to-securely-manage-secrets-with-hashicorp-vault-on-ubuntu-16-04" on how to install and access secrets from vault. It is PCI complaint and can be used to store very sensitive information. Fortunately there is a library from spring which you can use to easily read secrets from vault. Refer this page for sample code and more "https://projects.spring.io/spring-vault/".
On the other hand there is an offering from Amazon web services called secrets manager. If you organization is using AWS and your apps are hosted in AWS environment it is quite easy for you to put secrets in secret's manager and access them. But secrets manager is not PCI complaint yet and is expected to be PCI complaint in the next upcoming months. Please refer to this video "https://www.youtube.com/watch?v=HiY2oxR1Jd0" on how to use secret's manager in your application.
Hope this helps you. Cheers !!
add a comment |
up vote
0
down vote
up vote
0
down vote
You can use some industry standard tools like Hashicorp's vault "https://www.vaultproject.io/" to store the secrets and retrieve them when required. Lot of big gaints use this tool to manage their secrets. You have to install vault in your organization's environment to access vault. You can refer to this article
"https://www.digitalocean.com/community/tutorials/how-to-securely-manage-secrets-with-hashicorp-vault-on-ubuntu-16-04" on how to install and access secrets from vault. It is PCI complaint and can be used to store very sensitive information. Fortunately there is a library from spring which you can use to easily read secrets from vault. Refer this page for sample code and more "https://projects.spring.io/spring-vault/".
On the other hand there is an offering from Amazon web services called secrets manager. If you organization is using AWS and your apps are hosted in AWS environment it is quite easy for you to put secrets in secret's manager and access them. But secrets manager is not PCI complaint yet and is expected to be PCI complaint in the next upcoming months. Please refer to this video "https://www.youtube.com/watch?v=HiY2oxR1Jd0" on how to use secret's manager in your application.
Hope this helps you. Cheers !!
You can use some industry standard tools like Hashicorp's vault "https://www.vaultproject.io/" to store the secrets and retrieve them when required. Lot of big gaints use this tool to manage their secrets. You have to install vault in your organization's environment to access vault. You can refer to this article
"https://www.digitalocean.com/community/tutorials/how-to-securely-manage-secrets-with-hashicorp-vault-on-ubuntu-16-04" on how to install and access secrets from vault. It is PCI complaint and can be used to store very sensitive information. Fortunately there is a library from spring which you can use to easily read secrets from vault. Refer this page for sample code and more "https://projects.spring.io/spring-vault/".
On the other hand there is an offering from Amazon web services called secrets manager. If you organization is using AWS and your apps are hosted in AWS environment it is quite easy for you to put secrets in secret's manager and access them. But secrets manager is not PCI complaint yet and is expected to be PCI complaint in the next upcoming months. Please refer to this video "https://www.youtube.com/watch?v=HiY2oxR1Jd0" on how to use secret's manager in your application.
Hope this helps you. Cheers !!
edited Nov 23 at 8:41
answered Nov 18 at 7:25
Keerthikanth Chowdary
85111
85111
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53188638%2fhow-can-i-not-push-my-api-keys-credentials-to-github-especially-public-repos%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
And don't forget the "damage control": git-scm.com/docs/git-filter-branch >
git-filter-branchallows you to make complex shell-scripted rewrites of your Git history, but you probably don’t need this flexibility if you’re simply removing unwanted data like large files or passwords.– Emil Vatai
Nov 11 at 8:18
The examples say
git filter-branch --tree-filter 'rm filename' HEADwould be the command to use.– Emil Vatai
Nov 11 at 8:25