Pages knowledge base article #2493
Conversation
|
@sknep 😀 |
|
|
||
| Adhering to a set of best practices when it comes to managing GitHub repositories can greatly ease the maintenance burden and drastically improve the developer experience for websites hosted on cloud.gov Pages. This document should serve as a constructive conversation piece for agencies and not as an audit mechanism. But by utilizing certain code scanning tools, agencies may find it easier to identify and cover certain security controls within their respective Customer Responsibility Matrix (CRM). Here is a useful guide for you to get started with implementing some best practices regarding user permissions and security for your GitHub hosted repositories. | ||
|
|
||
| ## **Public vs Private repositories** |
There was a problem hiding this comment.
| ## **Public vs Private repositories** | |
| ## Public vs Private repositories |
There was a problem hiding this comment.
Going to rework the language so enhanced security isn't implied in any way.
| ### **Public** | ||
|
|
||
|
|
||
| #### **Pros** |
There was a problem hiding this comment.
| #### **Pros** | |
| #### Pros |
| - Compliance with open source and transparency initiatives per agency/program | ||
|
|
||
| #### **Cons** | ||
| - Any sensitive information inadvertently hardcoded is immediately visible |
There was a problem hiding this comment.
Since all published sites are public, the information would probably affect both public and private repositories. I don't want to inadvertently give a customer a false sense of security with a private repo.
There was a problem hiding this comment.
Understood but if someone committed API keys to a _config.yml file for example in a private repository is that exposed anywhere other than in the build logs? That's more so what I was looking to convey
There was a problem hiding this comment.
It starts to become very specific to the static site build engine and how they use their configuration settings. Many attributes in a Jekyll _config.yml get included with the site output. Let's leave this Any sensitive information inadvertently hardcoded is immediately visible here since it is true and let's adjust the other one to be very explicit.
| - Restrict access to authorized collaborators and contributors (for any support issues a Pages engineer will request to be added as a collaborator to the repository if necessary) | ||
| - Risk mitigation | ||
| - Test/Make changes to a website without exposing commits to the public | ||
| - Safeguard against any potential leaks of sensitive information |
There was a problem hiding this comment.
Like the con for a public repo, Since all published sites are public, I don't want to inadvertently give a customer a false sense of security with a private repo.
There was a problem hiding this comment.
switched it up to explicitly state for any config files
|
|
||
| #### Pros | ||
| - Test/Make changes to a website without exposing commits to the public | ||
| - Safeguard sensitive data such as API keys, access tokens or other credentials in any configuration files by storing them as environment variables in `config.yml` for Jekyll sites or using `dotenv` to load values from a separate `.env` file for 11ty, Gatsby and Node.js websites as an additional layer of privacy. |
There was a problem hiding this comment.
| - Safeguard sensitive data such as API keys, access tokens or other credentials in any configuration files by storing them as environment variables in `config.yml` for Jekyll sites or using `dotenv` to load values from a separate `.env` file for 11ty, Gatsby and Node.js websites as an additional layer of privacy. | |
| - Safeguard sensitive data such as API keys, access tokens or other credentials by [using environment variables](https://cloud.gov/pages/documentation/env-vars-on-pages-builds/) in our build runtime. |
|
Closes cloud-gov/product#2952 |
Changes proposed in this pull request:
Security Considerations
N/A