\u201cA secret is a piece of sensitive information. For example, an API key, password, or any type of credential that you might use to access a confidential system.\u201d<\/em><\/strong><\/p>\n\n\n\n
As you can see above, the loss of secrets in information systems has far-reaching consequences, because data loss can cause huge financial losses, a breakdown in trust, or even the complete end of our business. So be careful! Keeping secrets is crucial.<\/p>\n\n\n\n
Where are secrets stored in GitHub?<\/h2>\n\n\n\n
Before we think about how and where we can hide such information, let\u2019s first answer the question \u2013 why put it in the repository at all?<\/p>\n\n\n\n
And the answer is very simple \u2013 GitHub Actions. Exactly, I mean the passwords necessary to run individual workflows. As an introduction to the topic and its security, I recommend reading one of our previous texts about GitHub Actions<\/a>.<\/p>\n\n\n\n Well, somehow GitHub needs this data to execute a specific job in our workflow<\/strong>. That is why a special storage mechanism for such secrets was created. We can create them on several levels: repository, environment, or organization.<\/p>\n\n\n\n When a workflow run is added to the queue, then organization and repository-level secrets are read. In turn, the environment-level secrets are accessed when the job starts.<\/p>\n\n\n\n We can, and even should, limit access to this secret information to the maximum by properly configuring access secrets. Make sure to properly grant access and permissions! For example, for environment-level secrets, we can assign a given reviewer who will manage access. Thanks to this, each workflow job will have to receive such access to be able to access a given secret<\/strong>. A very useful function and extremely important from the security perspective and management of our project.<\/p>\n\n\n\n Let me show you now how easy it is to add a secret. It looks similar for all three levels, i.e. in the Settings tab, we have to select the appropriate option and then create a secret that interests us. Before we get started, it\u2019s also worth reading about the naming convention and GitHub secrets pattern<\/strong>. For our needs, I will quote three important points regarding the nomenclature:<\/p>\n\n\n\n More information can be found in the official documentation<\/a>.<\/p>\n\n\n\n To create repository secrets or environment-level secrets you must be either the repository owner or you must have admin access to it. Environment secrets play a crucial role in enhancing security by allowing the creation and management of secrets at an environment level, ensuring that only authorized reviewers can approve workflow runs that access these secrets.<\/p>\n\n\n\n For the organization level, you also need to have admin access but in addition, you can use a policy for a personal account repository. So here is the answer to the question \u201cWho can see GitHub secrets?<\/strong>\u201d. It depends on the access to the repository\/organization. Please be aware that anyone who can create or edit the workflow file can also use and read encrypted secrets in that workflow.<\/p>\n\n\n\n \ud83d\udca1 PRO tip:<\/strong> Converting plain text files into an encrypted file using tools like SOPS or gpg is crucial for maintaining security while allowing certain parts to remain in plaintext for ease of access.<\/em><\/p>\n\n\n Every secret you need to create on the Settings menu in GitHub. Either on the repository or organization level.\u00a0<\/p>\n\n\n\n First, we have to choose the environment we are interested in, and then in the lower section of this submenu, we will find a place where the secrets that have already been created are kept. Of course, we can add a new one at any time.<\/p>\n\n\n\n It is worth returning to the topic of access protection and the security of our secrets. It is for this level that we can add additional protection rules like manual approvals and timeouts or even branch limitation rules:<\/p>\n\n\n First, we have to choose the environment we are interested in, and then in the lower section of this submenu, we will find a place where the secrets that have already been created are kept. Of course, we can add a new one at any time.<\/p>\n\n\n\n It is worth returning to the topic of access protection and the security of our secrets. It is for this level that we can add additional protection rules like manual approvals and timeouts or even branch limitation rules:<\/p>\n\n\n Here, the matter is quite obvious, we enter the repository we are interested in, select the Settings menu at the top, then the Secrets submenu, here we choose whether we are focused on Actions or Dependabot level, and then click the \u201cNew repository secret\u201d button.<\/p>\n\n\n\n From this level, if our repo also has environment or organization secrets, they will be shown here too:<\/p>\n\n\n You can also manage a secret file by encrypting sensitive files using gpg before committing them to the repository, ensuring that secrets are not revealed in workflow logs.<\/p>\n\n\n\n When creating our actions, we can easily refer to the secrets prepared in such a way through a simple context \u201csecrets\u201d. Thanks to this, we can be sure that even when someone gains access to the definition of our action or the entire repo (but without admin access), our data will still remain safe and our secret values will be hidden.<\/p>\n\n\n There is also the issue of safety and best practices. GitHub in its documentation warns that it will automatically redact secrets printed to the log, and at the same time encourages us not to print this information to the log intentionally.<\/p>\n\n\n\n Another way to increase our security is to mask values in logs. To do this, we must precede the given log with the sequence ::add-mask::<\/strong>, and as a result, instead of printing the critical data, the \u2018*\u2019<\/strong> symbols will appear in the log. Examples of the use of such masks:<\/p>\n\n\n\n echo \u201c::add-mask::${{ secrets.MY_SECRET }}\u201d<\/em><\/strong><\/p>\n\n\n\n It is also worth paying attention to any third-party GitHub actions in our project. To be clear, I do not advise against using them. On the contrary. We just have to be careful because we are ultimately responsible for what we do with our project. It\u2019s a good idea to fork a given action and then use it in our project. Then we have a guarantee that no one from the outside will change its operation.<\/p>\n\n\n\n All in all, using GitHub action secrets is a good solution, and with the right level of control and consideration, it is a secure solution to keep your passwords private. Remember to carefully grant permissions in our repositories and control them on an ongoing basis. In case of any threat or attack, any user with write access can create a dedicated workflow to expose our secrets.<\/p>\n\n\n\n [FREE TRIAL] Ensure compliant DevOps backup and recovery with a 14-day trial<\/strong><\/a> \ud83d\ude80<\/strong> Everyone has a secret. Small or big, it doesn’t matter. The important thing is that each of us hides such a secret from the world for a variety of reasons. But there’s one thing all secrets have in common \u2013 no one wants them to become public! In the IT world, this is doubly important and I will explain why in a moment. But first, let’s clarify what \u201csecret\u201d means. Let me quote a short definition from the IBM website:<\/p>\n","protected":false},"author":6,"featured_media":2633,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-2625","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-github","post--single"],"yoast_head":"\nHow to add the secrets in GitHub?<\/h2>\n\n\n\n
\n
![\"Get](\"https:\/\/gitprotect.io\/blog\/wp-content\/uploads\/2022\/03\/LinkedIn-ads-template-1024x536.png\")
<\/a><\/figure><\/div>\n\n\nEnvironment level<\/h3>\n\n\n\n
![\"Setting](\"https:\/\/lh6.googleusercontent.com\/W6zVNL2DOl9Bx-w-xoQzU5qe5x-J89uz5U-2AKgNkMQFVBkcY7ZfqOvNnKPgTN8bnWG-w8jg9bheT7fHhzr25Y7LNtlOFTGS2cY14RYr_Zi9xZlxJ1rlbcubenMrea7UJrhhL8ek\")
Organization level<\/h3>\n\n\n\n
![\"Setting](\"https:\/\/lh5.googleusercontent.com\/HEskXAinXQcHAO4QYYYErmxfa8SlZ5flm4BQGHew50Ma2USBgDX5tAEOiYSthgJkor1Ofujaqjh_uz1syBlOoe_YtBRZ4DWfH9jBuLgJIDkohMZjIQYAbdDvLCb__poiNAbfqlHX\")
Repository level<\/h3>\n\n\n\n
![\"Setting](\"https:\/\/lh3.googleusercontent.com\/XW7xxMzoOxEX1RcbFppVApil3KrGe76KhCqJmh-yh6sNwP8NrX0iFCd-MKn1XoFjHC6MVwBF4ZFx5ytr6vuCbWiIFYXtNaHolLq6uvdsWw7Eq5rBk9r9q_lDCBFTCf896Hrx2Q1I\")
GitHub Actions secret example<\/h2>\n\n\n\n
![\"GitHub](\"https:\/\/lh3.googleusercontent.com\/-ChpFpCsaQnxj4bma_kERuALe1aKSh6DvSIfMuzxazVAUaSr19Hw5HPjv098irrsB4C6lpSWvfZiJ3vGXBRzLx_WdhKc7zqN_txLsnxTW0aa7WZS--P2by_5KB7NyWP6FZWfgvPV\")
Conclusion<\/h2>\n\n\n\n
[CUSTOM DEMO] Let\u2019s talk about how backup & DR software for DevOps can help you mitigate the risks<\/strong><\/a><\/p>\n","protected":false},"excerpt":{"rendered":"