Administrative API and improved tribal data API access controls (#2860)

* Seems to run... backs up between buckets

Uses a Python-based approach and a Django command as opposed to a shell
script.

Lots of issues with configuration; this would want to be
refactored/improved after we improved how configuration for the app as a
whole takes place.

It should be much easier to access buckets, etc. regardless of the
environment we are working in (local, prod).

* Forgot `handle()`.

* Moving files around

This proabbly belongs in support as an admin API.

* Can add, remove, and check keys.

* Moving everything to UUIDs.

This moves both admin access and tribal data access to a table that is
explicitly created via INSERTs that are static/loaded at creation-time.

The intent (which could be enforced by schema/privileges) would be to
have a table that cannot be modified by the Postgrest user. This way, we
have a table that is lookup-only. This would require creating a schema
for the table, and prohibiting anything but SELECT perms on that schema
from the api_fac_gov user.

For now, this is still "for discussion." I have tests to add, etc. This
looks very promising, however.

The admin functions "work." The file "test.rest" in
support/api/admin_api_v1_0_0 allow some quick experimentation. They'll
want to be turned into Python functions that run locally/in GH Actions
as part of a test suite.

* Updating functions to bulk add, adding comments.

* This should not have been in this branch.

* Fixing errors

This brings everything up, and tests are underway.

* Adds test coverage for core functions

Need to add multi-add.

* More tests.

* Makes sure we cannot access the view

* Linting.

* Remove 'assert' statements

* One more assert? Linting.

* Tests, comments

Also, using a slug and SELECT to get rid of a magic number.

* Updating test code, view query

* Need select on the tribal access table

The public views rely on that table, so SELECT access is needed.

This fixes the Cypress tests.

* Might be more correct to include the table space.

Added `public.`... to the table name.

* API access request

Addresses a review question, of how we initiate this process/track it.

The issue template can be used/required for adding people.

* Improving comment, removing code

Removed unused function.

Removed comments of unneeded code.

Improved comment around process. Github issue template created.

* Updating TF for Admin API

Forgot this has to be done in order to test on `preview`.

* Updating profile to test a migration failure.

* Removing the errant migration

Removing it completely.

* Refactoring run.sh/.profile

This was ultimately a variety of problems, but part of it was our
confusing .profile/run.sh situation.

Everything is now:

1. A function
2. Has error checking
3. Is reused between the two scripts

* Historic tables are not ready.

Commenting out until the VCAP grab is fixed.

* Updates API code for PG15

The public site (for tribal data access via API) still needs to be
updated.

However, there are no users (yet) hitting that, so it is behaving
correctly (blocking access).

This enables the Admin API to work in production (probably).

* Reverting to `main` on a migration.

* Fixes from review.

Separates functions out so they are not on the API schema.

* Updates from review.

1. Adding functions to their own (not-exposed) schema.
2. Making tests run always.

* Adding DS for tribal access API.

* Satisfying the linter.

* Lint.

* Fixing... parallel test issue?

* lint

---------

Co-authored-by: danswick <[email protected]>

.github/ISSUE_TEMPLATE/api-access-template.yaml

@@ -0,0 +1,37 @@
+name: Request for administrative API access
+description: Used to record when and why we granted increased permissions on an API.
+title: "[API access]: "
+labels: ["api"]
+projects: ["GSA-TTS/11"]
+assignees:
+  - jadudm
+  - danswick
+body:
+  - type: markdown
+    attributes:
+      value: |
+        A request for elevated API access is recorded for reasons of security and compliance.
+
+        * A request for *tribal data access* will begin a process that requires additional conversation with the agency involved. 
+          Access will only be granted to designated staff at confirmed agency partners.  
+        * A request for *admniistrative API access* will only be granted to members of the GSA FAC team.
+
+  - type: dropdown
+    id: accesstype
+    attributes:
+      label: Access type
+      description: What kind of access is being requested?
+      options:
+        - Administrative API access
+        - Tribal data access API 
+      default: 0
+    validations:
+      required: true
+  - type: input
+    id: email
+    attributes:
+      label: Email address
+      description: What is your email address?
+      placeholder: ex. [email protected]
+    validations:
+      required: true