Storing Credentials in AWS, Kubernetes, CI/CD
Credentials and other secrets of your application must be secured all the time. In times of compromise access to credentials can have a detrimental effect on your systems and data. Because DevOps involve different systems like AWS, Kubernetes, Jenkins, there is no single way to store credentials. This post discusses some ways to store the credentials for your application in a more secure manner.
No Credentials in code Repository | 0 | heading |
This is a very common mistake among developers while pushing code to code repositories like Github, Bitbucket, or Gitlab. While running a code locally your application may use credentials to connect to a database or other application. Therefore you update the credentials in your config file. But while pushing the code to the repository if you forget to delete the credentials your credentials may be exposed to anyone who has access to the code. This is even worse if your code is being used by a third party. Once credentials are in the repository it is difficult to clean because even if you delete the config file there is still a trace of credentials in the commit. So you also need to remove those commits and readjust the head of your code branch. One good solution is to always store credentials in environment variables and let your application access these credentials through the environment. In that way, you don't have to remember to clean your config files while pushing your code. | 1 | paragraph |
Using Credentials in Jenkins/Gitlab-CI/CircleCI or other CI/CD tools | 2 | heading |
While running your workflows in CI/CD pipelines inside Jenkins or other tools like Gitlab-CI or CircleCI you need to access credentials to run unit tests or create builds. Most of these tools have configurations to set your credentials and can be accessed during the build process. There are also different levels of authorizations so one can run a pipeline but won't be able to access these credentials. It's also a good idea to let these tools set environment variables and your provisioning code can access these variables. Care must be taken that credentials are not logged into the pipeline logs. | 3 | paragraph |
Credentials in AWS EC2 nodes and other computes | 4 | heading |
| 5 | list |
Credentials in Kubernetes | 6 | heading |
Promoted Promoted
| 7 | list |
Credentials in S3 or other Datastore | 8 | heading |
This is not recommended but in some cases there might be secret files or sensitive data in the S3 bucket or other Datastore. If there is any, these files need to be encrypted with a proper passcode. | 9 | paragraph |
Check credentials leak in Logging | 10 | heading |
Sometime inadvertently sensitive information or secrets are leaked to logging services by applications. Therefore proper security is provided for logging services. You might use encryption or some obfuscation if such data is leaked to a logging service. In ideal case there should be no secrets in logs. | 11 | paragraph |
Recommendations | 12 | heading |
| 13 | list |