Issue 967: Dynamically generate DJANGO_SECRET_KEY for initial deployments

[jtwillis92]

Summary of Changes

Closes #967

Introduces dynamic generation of DJANGO_SECRET_KEY for initial deployments to Cloud.gov and provides a generated default in the event it is not set.

How to Test

• Remove DJANGO_SECRET_KEY from CircleCI environment variables (done on Raft side)
• Run Circle CI checks and ensure no failures result from removing DJANGO_SECRET_KEY
• Pick a development app to target
• Delete that development app from Cloud.gov, using the UI or CLI:

cf delete [target-app]

• Assign the relevant label to deploy this PR to the target app
• Ensure that DJANGO_SECRET_KEY is set to a random string 67 characters in length after the deployment is completed

cf env [target-app]
python -c "print(len('[COPY GENERATED KEY HERE]'))"

• Reset the Login.gov keypair for the target app

./scripts/copy-login-gov-keypair.sh [any-other-dev-app] [target-app]

• Finally, log into the deployed app and make sure everything works as expected

Deliverable 1: Accepted Features

Performance Standard(s): At the beginning of each sprint, the Product Owner and development team will collaborate to define a set of user stories to be completed during the sprint. Acceptance criteria for each story will also be defined. The development team will deliver code and functionality to satisfy these user stories.

Acceptable Quality Level: Delivered code meets the acceptance criteria for each user story. Incomplete stories will be assessed and considered for inclusion in the next sprint.

• Look up the acceptance criteria in the related issue; paste ACs below in checklist format.
• Check against the criteria:
  • DJANGO_SECRET_KEY is automatically generated for initial deployments to Cloud.gov
  • Testing Checklist has been run and all tests pass
  • README is updated, if necessary

As facilitator/product manager, @kniz-raft will decide if ACs are met from Raft's perspective.

Deliverable 2: Tested Code

Performance Standard(s): Code delivered under the order must have substantial test code coverage. Version-controlled HHS GitHub repository of code that comprises products that will remain in the government domain.

Acceptable Quality Level: Minimum of 90% test coverage of all code. All areas of code are meaningfully tested.

N/A, configuration change

Deliverable 3: Properly Styled Code

Performance Standard(s): GSA 18F Front- End Guide

Acceptable Quality Level: 0 linting errors and 0 warnings

N/A, configuration change

Deliverable 4: Accessible

Performance Standard(s): Web Content Accessibility Guidelines 2.1 AA standards

Acceptable Quality Level: 0 errors reported using an automated scanner and 0 errors reported in manual testing

N/A, configuration change

Deliverable 5: Deployed

Performance Standard(s): Code must successfully build and deploy into the staging environment.

Acceptable Quality Level: Successful build with a single command

NOTE: until we have a proper staging environment this may not be satisfiable prior to merging

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

Performance Standard(s): Summary of user stories completed every two weeks. All dependencies are listed and the licenses are documented. Major functionality in the software/source code is documented, including system diagram. Individual methods are documented inline in a format that permits the use of tools such as JSDoc. All non-inherited 800-53 system security controls are documented in the Open Control or OSCAL format and HHS Section 508 Product Assessment Template (PAT) are updated as appropriate.

Acceptable Quality Level: Combination of manual review and automated testing, if available

N/A, configuration change

Deliverable 7: Secure

Performance Standard(s): Open Web Application Security Project (OWASP) Application Security Verification Standard 3.0

Acceptable Quality Level: Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any security issues?

[jtwillis92]

This is simply a convenience script for developers, it is not called by any other methods. This is something I've had in my scratch files for awhile and have been using it to restore Login.gov credentials back to an application that has been deleted and re-created. Otherwise we would have to update the certificate in Login.gov and pass out the newly generated key to developers. Note that this does not replace the JWT rotation documentation, this is only suitable when it is desired to keep the current Login.gov keypair.

[jtwillis92]

This is the key change, setting this here will overwrite what is stored in Circle CI for this variable (if anything). Uses the new (as of Python 3.6) secrets module in the standard library.

[jtwillis92]

By supplying a default here we prevent a possible KeyError when that environment variable is not set and instead use a secure, newly generated value. This also allows us to remove this variable declaration from the docker-compose.yml and Circle CI project settings.

[codecov]

Codecov Report

Merging #1151 (30c57ef) into raft-tdp-main (5bb6d9a) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@              Coverage Diff               @@
##           raft-tdp-main    #1151   +/-   ##
==============================================
  Coverage          98.13%   98.13%           
==============================================
  Files                 38       38           
  Lines                910      911    +1     
  Branches              41       41           
==============================================
+ Hits                 893      894    +1     
  Misses                12       12           
  Partials               5        5           

Flag	Coverage Δ
dev-backend	98.13% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
tdrs-backend/tdpservice/settings/common.py	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 5bb6d9a...30c57ef. Read the comment docs.

[andrew-jameson]

LGTM

[ADPennington]

test results below 👍🏾

• confirmed that django_secret_key not an ev in hhs circleci (re: Update O&M Manual w/ correct ENV variables on frontend/backend Cloud.gov apps + HHS CircleCI project settings #896) ✅
• deleted tdp-backend-qasp via cf cli; confirmed via UI ✅
• deployed via qasp label; all checks passed ✅
• confirmed that django_secret_key generated with len = 67 ✅
• reset login.gov keypair (used tdp-backend-a11y as ref); restaged tdp-backend-qasp app ✅

- confirmed its up ✅

[ADPennington]

thanks @jtwillis92 👍🏾 @abottoms-coder this is ready to merge.

Deliverable 1: Accepted Features

Performance Standard(s): At the beginning of each sprint, the Product Owner and development team will collaborate to define a set of user stories to be completed during the sprint. Acceptance criteria for each story will also be defined. The development team will deliver code and functionality to satisfy these user stories.

Acceptable Quality Level: Delivered code meets the acceptance criteria for each user story. Incomplete stories will be assessed and considered for inclusion in the next sprint.

• Look up the acceptance criteria in the related issue; paste ACs below in checklist format.
• Check against the criteria:
  • DJANGO_SECRET_KEY is automatically generated for initial deployments to Cloud.gov
  • Testing Checklist has been run and all tests pass

As Product Owner, @lfrohlich will decide if ACs are met.

Deliverable 2: Tested Code

Performance Standard(s): Code delivered under the order must have substantial test code coverage. Version-controlled HHS GitHub repository of code that comprises products that will remain in the government domain.

Acceptable Quality Level: Minimum of 90% test coverage of all code. All areas of code are meaningfully tested.

• Are all areas of code introduced in this PR meaningfully tested?
  • If this PR introduces backend code changes, are they meaningfully tested?
    mostly just config changes; minor backend chg to prevent keyerror
• Are code coverage minimums met?
  • Backend coverage: ___ (see https://github.com/raft-tech/TANF-app README coverage dashboard)

Deliverable 3: Properly Styled Code

n/a

Deliverable 4: Accessible

n/a

Deliverable 5: Deployed

Performance Standard(s): Code must successfully build and deploy into the staging environment.

Acceptable Quality Level: Successful build with a single command

• Was the code successfully deployed via automated CircleCI process to development on Cloud.gov?

Deliverable 6: Documented

Performance Standard(s): Summary of user stories completed every two weeks. All dependencies are listed and the licenses are documented. Major functionality in the software/source code is documented, including system diagram. Individual methods are documented inline in a format that permits the use of tools such as JSDoc. All non-inherited 800-53 system security controls are documented in the Open Control or OSCAL format and HHS Section 508 Product Assessment Template (PAT) are updated as appropriate.

Acceptable Quality Level: Combination of manual review and automated testing, if available

• If this PR introduces backend code, is that code documented both inline and overall?
• If this PR introduces dependencies, are their licenses documented?
  secrets from https://github.com/python/cpython/blob/main/LICENSE

Deliverable 7: Secure

Performance Standard(s): Open Web Application Security Project (OWASP) Application Security Verification Standard 3.0

Acceptable Quality Level: Code submitted must be free of medium- and high-level static and dynamic security vulnerabilities

• Does the OWASP Scan pass on CircleCI?
• Do manual code review and manual testing detect any security issues?
  no new issues detected