USAGOV-1761-cf-components-audit: Created cf components audit script

[jacobaaronyeager]

Jira Task

https://cm-jira.usa.gov/browse/USAGOV-1761

Description

Script for auditing components in cf environment.

Type of Changes

• New Feature
• Bugfix
• Frontend (Twig, Sass, JS)
  • Add screenshot showing what it should look like
• Drupal Config (requires "drush cim")
• New Modules (requires rebuild)
• Documentation
• Infrastructure
  • CMS
  • WAF
  • Egress
  • Tools
• Other

Testing Instructions

Run bin/cloudgov/audit/cf-components

Security Review

• Adds/updates software (including a library or Drupal module)
• Communication with external service
• Changes permissions or workflow
• Requires SSPP updates

Reviewer Reminders

• Reviewed code changes
• Reviewed functionality
• Security review complete or not required

Post PR Approval Instructions

Follow these steps as soon as you merge the new changes.

1. Go to the USAGov Circle CI project.
2. Find the commit of this pull request.
3. Build and deploy the changes.
4. Update the Jira ticket by changing the ticket status to Review in Test and add a comment. State whether the change is already visible on cms-dev.usa.gov and beta-dev.usa.gov, or if the deployment is still in process.

[akf]

This is looking promising and I've learned some things, like the fact that back in 2019 someone created a my.rubytest.gov domain in the sandbox-gsa org. I've also realized that I really should review this kind of script carefully before just running it! (Nothing bad happened, but if you were a bad actor it could have.)

This is slow, and after watching several screens of vote-SPACE-upkeep tasks list out in my terminal, I think we need to make some changes:

1. Don't list the tasks, just show the count of tasks and move on. I see that the tasks endpoint provides pagination with a total_results value.
2. Limit everything to the gsa-tts-usagov org. Maybe take the organization as an optional argument (and if it's not provided, do all orgs).
3. Similarly, provide a way to specify which spaces to list.
4. If listing all orgs, DO NOT list out the users. I'm getting all the users in the sandbox-gsa org. I think that's basically every engineer doing work for TTS and using cloud.gov. Or actually, no ... I'm just getting the first page of users
5. Skip the buildpacks you're getting under "misc info." I got a list of several buildpacks we don't use, and it's missing some that we do (apt_buildpack, for example). I don't know if this is just standard buildpacks or what. (The buildpacks listed for specific apps look correct, though.)

And, I'm sorry, it looks like this needs to account for pagination.

[jacobaaronyeager]

This is looking promising and I've learned some things, like the fact that back in 2019 someone created a my.rubytest.gov domain in the sandbox-gsa org. I've also realized that I really should review this kind of script carefully before just running it! (Nothing bad happened, but if you were a bad actor it could have.)

This is slow, and after watching several screens of vote-SPACE-upkeep tasks list out in my terminal, I think we need to make some changes:

1. Don't list the tasks, just show the count of tasks and move on. I see that the tasks endpoint provides pagination with a total_results value.
2. Limit everything to the gsa-tts-usagov org. Maybe take the organization as an optional argument (and if it's not provided, do all orgs).
3. Similarly, provide a way to specify which spaces to list.
4. If listing all orgs, DO NOT list out the users. I'm getting all the users in the sandbox-gsa org. I think that's basically every engineer doing work for TTS and using cloud.gov. Or actually, no ... I'm just getting the first page of users
5. Skip the buildpacks you're getting under "misc info." I got a list of several buildpacks we don't use, and it's missing some that we do (apt_buildpack, for example). I don't know if this is just standard buildpacks or what. (The buildpacks listed for specific apps look correct, though.)

And, I'm sorry, it looks like this needs to account for pagination.

These have been addressed.

[akf]

I'm giving this another look. I see a couple of error messages; here they are with a line of context above and below:

     gsa.benefits.gov (Last updated: 2024-08-23T18:08:43Z | Internal: false | Supported Protocols: ["http"])
curl: (3) URL rejected: No host part in the URL
bin/cloudgov/audit/cf-components: line 96: [: -gt: unary operator expected
   Space: stage (Last updated: 2024-08-08T20:48:19Z)

So this is telling me the second error message occurs on line 96. Probably the other error is from the command on line 95 (which I notice doesn't have $() around the cf curl command).

[akf]

In addition to that error message I commented on earlier, I'm unfortunately seeing that this report is missing a lot of information.

What I did was run:

bin/cloudgov/audit/cf-components > cf-components.txt

I didn't supply any arguments, although I see that I could. I'm pleased that it limited its queries to the gsa-tts-usagov org.

I didn't dig into the code because I'm short on time; I'm just critiquing the output.

The output is in https://docs.google.com/document/d/1RyKRFbsvoeTKvM2frwYjSNzHzi8SycO35DjBNtTrpnU/edit and I've commented on specific parts, but the main themes are:

• many of the lists are missing information (e.g., we have more services than show up). I saw this specifically for:
  • domains
  • services (in one case I didn't get any services even though there are several I see when I use cf services to list them)
  • routes
• The Security Groups listing tells me the rules for the security groups that are available, but not where we're using them -- which is what we really need. Take a look at what "cf security-groups" shows -- you get a table of name, organization, space, and lifecycle (running or staging). It makes sense for us to look for things like "public_networks_egress is associated with a non-egress space in the running lifecycle stage"

I did get all the apps in my listings, and I can't help wondering whether that's just because the lists of apps are short!