No Credentials in code Repository

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.

Using Credentials in Jenkins/Gitlab-CI/CircleCI or other CI/CD tools

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.

Credentials in AWS EC2 nodes and other computes

• If you are using EC2 nodes and need to access other AWS services you should use the IAM instance role. Create a role for your instance and attach that role while creating the instance. Make sure no AWS key and secrets are stored inside the instance.
  
• In case your application needs credentials to run, use the AWS parameter store. Create KMS key first. Create a name for credentials and then store your value by encrypting it with a KMS key. Before running the application pull these credentials and store them in environment variables. After the application runs successfully, clear these environment variables. This can be automated using python, bash, or ansible.
  
• If you are not a fan of AWS parameter stores you can also use Hashicorp Vault.
  

Credentials in Kubernetes

Credentials in S3 or other Datastore

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.

Check credentials leak in Logging

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.

Recommendations

• Application code and credentials should not be stored together
  
• Delete the credentials if its not used anymore
  
• Never print credentials to any logs
  
• Always encrypt credentials with the proper key. Also make sure the key is rotated after some time
  
• Never share the same credentials between users. Each user should have its own set of credentials. Always check the authorization of these credentials.
  
• Never share the same credentials between users. Each user should have its own set of credentials. Always check the authorization of these credentials.
  
• Check access of each user or application through AWS cloudtrail.
  
• Always do a security audit after a certain period.