Identity production checklist

[brandur]

• [x] Set up a high-fidelity staging replica. note: see "installations" in README
• [x] Add to the platform lifecycle board
• [ ] Request an audit by the security team - this may be backlogged or handled immediately. note: sitting down with Tom on this one tomorrow
• [x] Has a Readme that explains how to run the app locally and create a personal platform deploy.
• [x] Has operational docs that provide executable instructions for common operational tasks.
• [x] Alerts a human if it is down. note: see "api: identity" on Watchtower
• [x] Has its code on Github in the Heroku organization.
• [x] Has undergone simulation testing to ensure graceful handling of degredation and failure modes. note: api failure will result in an "internal server error" page; not the most graceful possible failure, but we can't do much better than that based on the nature of the product
• [x] Uses structured logging.
• [x] Minimizes external service dependencies (e.g. using an existing Postgres database instead of Redis for OpenId).
• [x] Enforces SSL access (redirects all http: over to https:).
• [x] Consider adding the app to the credroll list on the employee exit checklist. note: stores no credentials so this isn't needed
• [x] Follows our availability best practices with heroku-production-check.
• [x] Does not depend on any development-level add-ons.
• [x] Does not have an unused add-ons installed.
• [x] Has an ERROR_PAGE_URL (if a web app). note: reusing Dashboard's for now
• [x] Has a MAINTENANCE_PAGE_URL (if a web app). note: reusing Dashboard's for now
• [x] Has been reviewed for OWASP top-10 app vulnerabilities.
• [x] Is owned by a Heroku Manager org. note: owned by heroku@herokumanager.org
• [x] Shows a suitable error page when encountering an internal error.
• [x] Has proper credentials (e.g. is not using your personal API key)
• [x] Drains app logs somewhere (e.g. splunk). note: goes to Splunk, search app=identity

[brandur]

All boxes ticked except the security review. Closing this in favor of #11.

[markpundsack]

For:

Has undergone simulation testing to ensure graceful handling of degredation and failure modes. note: api failure will result in an "internal server error" page; not the most graceful possible failure, but we can't do much better than that based on the nature of the product

How about detecting maintenance mode and displaying a different page; at least the static page api.heroku.com would have displayed in the same circumstance?