Using Pages places certain responsibilities on you as the government user of Pages. GSA has many internal sites running on Pages, but GSA cannot guarantee that Pages is compatable with your agency’s specific policies.
Pages retains other responsibilities, clarified below. The intent of these policies is to empower you to use Pages to its full potential with awareness of your responsibilities when using advanced features.
You must use a GitHub account to log onto Pages.
Pages is a service that leverages GitHub repositories for publishing. Pages eliminates redundancy by allowing GitHub users with editing access to a repository to configure the site on Pages. This requires Pages users to authorize the Pages application on their GitHub account and for Pages to be approved by the parent organizations of repos that are hosted with Pages. Pages users must also have two factor authentication enabled for their GitHub accounts in order to be given access.
GitHub is used across the government (see this dashboard from our partners in GSA’s Office of Government-wide Policy), and a majority of cabinet agencies have a GitHub presence. However, GSA does not endorse Github and there are other ways to launch sites if your agency is not prepared to use GitHub. At this time, no prospective Pages customer has been deterred by integration with GitHub.
You own your content
Pages provides templates for you to start with in configuring your sites, but is not responsible for editing or updating the content or local configuration of your site. The Pages team ensures that the publishing mechanism remains available to you so that your content edits can be published within minutes. Your content must be low impact according to FIPS 199 and each branch on GitHub is published publicly by Pages. Pages is not suitable for hosting the following types of information:
- PII (Personally Identifiable Information)
- FOUO (For Official Use Only)
- CUI (Confidential Unclassified Information)
- Classified Information
- other content that otherwise requires authorization to view
Pages suggests that you add your point of contact to your repo with editing rights for troubleshooting purposes, but this is not required.
You own your code
You are responsible for ensuring compliance with any and all additional federal regulations, including the 21st Century IDEA.
You own your domain and DNS
Pages does not manage your domain name nor provide DNS services. To launch a site on Pages, you must configure the DNS for your domain to point to a domain provided by the Pages team (meaning, that visitors to that address will be pointed at Pages so they can load your site from us). Setting DNS for a new or existing domain may involve working with other offices at your agency; these processes typically vary.
If your domain is not an apex (e.g. 2nd level) domain, the process may be more challenging as some DNS providers do not support all required DNS record types. We recommend that you plan a solution before signing an agreement, please see custom domains for more details.
SPF, DMARC, and MTA-STS records
GSA IT requires that your your URL’s apex domain has appropriately set DMARC and SPF records in accordance with BOD 18-01.
Expected DMARC record:
v=DMARC1; p=reject; pct=100; fo=1; ri=86400; rua=mailto:email@example.com,mailto:firstname.lastname@example.org; ruf=mailto:email@example.com
Expected SPF record:
SMTP MTA Strict Transport Security (MTA-STS) is a new standard that can enable domain names to opt into the strict transport layer security mode for email that requires public certificates and encryption. This standard may not be supported by all email providers but we encourage our customers to use this standard if possible when using the domain for email. See the standard (RFC 3207).
Expected MTA-STS record:
_mta-sts.example.gov IN TXT "v=STSv1; id=<id-value>"
_smtp._tls.example.gov IN TXT "v=TLSRPTv1; rua=reporting-email-address"
id-value identifies the MTA-STS policy in use and
reporting-email-address will be where you TLS reports will be sent. The
reporting-email-address can be prefixed with
mailto:firstname.lastname@example.org or sent to a URL like an API endpoint.
We control access to the core Pages codebase.
Access to Pages’ configuration tools for your specific content does not grant you access to Pages’ “backend.” Pages’ code is open source, but only approved members of the Pages team are allowed to make or approve changes. No one can access Pages’ management tools in cloud.gov without FedRAMP-approved two factor authentication.
We control access to the hosting service that serves your webpages
Pages moves content from your GitHub repositories into a secure build process and then into a file storage system that holds your site files. The credentials for the file storage system (Amazon S3 for those familiar) are secured within cloud.gov.
We maintain customer build logs for 180 days
In accordance with cloud.gov’s log retention policy, we will store logs from customer builds for 180 days, after which they will no longer be available.