Configure New Relic

[mogul]

No description provided.

[github-actions]

Terraform plan for management

No changes. Your infrastructure matches the configuration.

No changes. Your infrastructure matches the configuration.

Terraform has compared your real infrastructure against your configuration
and found no differences, so no changes are needed.

✅ Plan applied in Deploy to the dev and management cloud.gov environments #74

[github-actions]

Terraform plan for dev

Plan: 1 to add, 2 to change, 0 to destroy.

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  + create
  ~ update in-place

Terraform will perform the following actions:

  # module.dev.cloudfoundry_app.swagger will be updated in-place
  ~ resource "cloudfoundry_app" "swagger" {
      ~ docker_image                    = "swaggerapi/swagger-ui:latest" -> "swaggerapi/swagger-ui"
        id                              = "9d37d378-b26e-44ca-9e53-994224c903b4"
      ~ id_bg                           = "************************************" -> (known after apply)
        name                            = "swagger"
        # (13 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

  # module.dev.cloudfoundry_user_provided_service.credentials will be created
  + resource "cloudfoundry_user_provided_service" "credentials" {
      + credentials = (sensitive value)
      + id          = (known after apply)
      + name        = "newrelic-creds"
      + space       = "06525ba3-19c2-451b-96e9-ea4a9134e8b9"
    }

  # module.dev-egress.module.egress-proxy.cloudfoundry_app.egress_app will be updated in-place
  ~ resource "cloudfoundry_app" "egress_app" {
      ~ environment                     = (sensitive value)
        id                              = "f90568e3-36de-4ba6-bd86-666b11429754"
      ~ id_bg                           = "************************************" -> (known after apply)
        name                            = "egress"
        # (17 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

Plan: 1 to add, 2 to change, 0 to destroy.

❌ Error applying plan in Deploy to the dev and management cloud.gov environments #74

[mogul]

I put the NEW_RELIC_LICENSE_KEY into the GitHub repository-level secrets. Let's review and merge this, and leave further customization of the newrelic.ini to future PRs!

[JeanMarie-PM]

You can run make lint locally to catch linting errors. You have have all the packages in place first - make compile, ptenv activate, etc.
We should probably create a make docker-lint

[mogul]

We should probably create a make docker-lint

It might help me. I have a hard time investing effort in installing and configuring a bunch of toolchain pieces locally that I only occasionally use! Also it would help keep everyone developing using the same versions of tools, and allow us to control updates explicitly. The devContainer spec is for addressing exactly these problems, but I haven't ever had time to invest in making one for any of my projects!

[asteel-gsa]

@mogul There is something we may want to consider, and we should probably have a discussion about it with @ChrisB-16. We should assess the "sensitivity" level of the data being ingested via new relic, and we should probably consider adding the newrelic.ini at some point, or if not, then we should export an evironment var to set high security mode to true. Documentation is provided here and can be utilized with the NEW_RELIC_HIGH_SECURITY var.

Something to noodle on for data security and submission.

[mogul]

That looks like something we'd definitely want to turn on for staging and prod. Devs might want it off for their local work and the dev environment though, so we should look into how hard it would be to have a separate account set up just for that.

Can you add a checklist item to the "Could" section of the main ATO issue? (Can't easily find it via the mobile client right now.)

[mogul]

Got it, it's #725. (The tasklists don't show up in GitHub Mobile so I wasn't sure if I had the right one.)

[asteel-gsa]

That looks like something we'd definitely want to turn on for staging and prod. Devs might want it off for their local work and the dev environment though, so we should look into how hard it would be to have a separate account set up just for that.

Can you add a checklist item to the "Could" section of the main ATO issue? (Can't easily find it via the mobile client right now.)

Another option we could do is just write it into the .profile as default. So if we are logging to the dev env, then we dont want it. Because it is a boolean and not a string, we shouldnt need to walk through the VCAP to determine if we need it. We already have the ENV based on the space_name.

if [$NEW_RELIC_ENVIRONMENT = 'dev'] then  
    export NEW_RELIC_HIGH_SECURITY = false
else
    export NEW_RELIC_HIGH_SECURITY = true
fi 

Just something to think about. It probably isnt a necessity now, but I think for our first implementation, it would be nice to set that value to false so we can see exactly what "sensitive" data is being sent to NR. My hunch, is that when we submit through the workflow, and the api returns back to the "browser" section of NR, it will likely contain sensitive data. I am fairly certain that would be just cause for a POAM, and we should implement this before we move into Staging/Production.

The other side of the coin, if the NR account for FAC is accessible via the whole TTS org, even for dev, we may want to turn this on anyway.

The other question, that perhaps @ChrisB-16 or @jadudm could answer, is exactly how sensitive the audit workflow is. If we are dealing with PII in any form, we should have this implemented anyway, because we probably don't want to be exposing PII to the NR telemetry for the entire org to see.

[mogul]

Another option we could do is just write it into the .profile as default. So if we are logging to the dev env, then we dont want it. Because it is a boolean and not a string, we shouldnt need to walk through the VCAP to determine if we need it. We already have the ENV based on the space_name.

if [$NEW_RELIC_ENVIRONMENT = 'dev'] then  
    export NEW_RELIC_HIGH_SECURITY = false
else
    export NEW_RELIC_HIGH_SECURITY = true
fi 

We can do that easily, sure, but if the feature is turned on server-side, then everything would be rejected from the dev environment...

If the agent is configured for high security via the UI but not locally, then the agent connections are rejected, and the agent will shut down. However, this won't shut down your application.

[mogul]

This PR should be ready to go btw, please review @JeanMarie-TTS!