[DevOps] Discovery on copying secrets necessary for Vista API backend to function into `vaec-cie`.

[ndouglas]

Description

• What are these secrets?
• What is their provenance?
• Can they be rotated automatically?
• Should they be rotated now?
• Is this immediately necessary?
• Why are they necessary?
• What is the appropriate protocol for handling them?

Tasks

• [x] [DevOps] Determine what secrets we have in place and document in this thread.
• [x] [DevOps] Open followup ticket(s) to address each as appropriate.

Acceptance Criteria

• [x] Secrets are documented in this thread.
• [x] A followup ticket is opened for each secret that needs to be managed in vaec-cie.

[ndouglas]

Secrets Manager

• DD_API_KEY: nbd there
• MGMT_PASSWORD: Password for the management interface
• JWT_CONFIGURATION: A JSON-encoded object like so:

  {
  "jwt.application.name": "OCTO-VISTA-API",
  "jwt.application.key": <some string>,
  "jwt.issuer": "gov.va.ovac.vetext.smsbatch",
  "jwt.ttl": "60",
  "jwt.refreshttl": "240",
  "jwt.clockSkew": "5",
  "jwt.audience": "VETEXT-SMS-BATCH",
  "jwt.public.key": <base64-encoded public key>,
  "jwt.private.key": <base64-encoded private key>,
  "jwt.ssoi.public.key": <base64-encoded public key>
  }

• AWS_ACCESS_KEY_ID: this could conceivably be an issue
• AWS_SECRET_ACCESS_KEY: this could conceivably be an issue
• VISTA_CONNECTORS (non-prod-only): A JSON-encoded object containing a list of objects like so:

  {
  "connectors": [
  {
    "primaryStation": "<number>",
    "jndiName": "java:jboss/vlj/tevivista" OR "java:jboss/vlj/vlj<number>",
    "ip": "10.x.x.x" OR "hostname.va.gov",
    "port": "<number>",
    "accessCode": "base64-encoded string",
    "verifyCode": "base64-encoded string",
    "encrypted": "true",
    "alwaysUseDefaultAsMin": "false",
    "enabled": "true"
  }
  ]
  }

• WILDFLY_CONFIGURATION (non-prod-only): A JSON-encoded object like so:

  {
  "datasource": {
  "host": "<rds cluster endpoint hostname I think>",
  "port": "5432",
  "databaseName": "<string>",
  "databaseUsername": "<string>",
  "databasePassword": "<string>"
  },
  "vistaLinkResourceAdapters": [
  {
    "jndiName": "java:jboss/vlj/tevivista" OR "java:jboss/vlj/vlj<number>",
    "poolName": "vljDevPool",
    "minPoolSize": "0",
    "maxPoolSize": "50",
    "prefill": "false",
    "useStrictMin": "false",
    "flushStrategy": "FailingConnectionOnly",
    "blockingTimeoutMillis": "30000",
    "idleTimeoutMinutes": "1"
  },
  ],
  "vistalinkLogLevel": "DEBUG",
  "vistaApiLogLevel": "DEBUG"
  }

• APP_CONFIG_SETTINGS (prod-only): A JSON-encoded object like so:

  {
  "name": "ecs-vista-api",
  "environment": "<env>",
  "configProfile": "<config-profile-name>"
  }

The configProfile points to a hosted configuration, which is roughly the same data as that managed in WILDFLY_CONFIGURATION on dev.

The problem I see here is that these aren't really consistent across environments. So I'm going to have to dig in here to see what is actually happening and how these are used.

[ndouglas]

• Why stuff is different between non-prod and prod
• Config generator

[ndouglas]

Tentative plan.

• DD_API_KEY is fine.
• MGMT_PASSWORD is fine, needs to be regenerated though
• JWT_CONFIGURATION is fine, should be generated though
• nuke WILDFLY_CONFIGURATION and VISTA_CONNECTORS
• AppConfig on every environment; add AppConfig to ECS task role policy.

[benbrasso-agile6]

Testing something with that label real quick

[ndouglas]

In summary, all of these that matter are provided by the Vista API Config Generator. These do not need to be copied, per se, but I need to verify experimentally that the appropriate resources will be created, and I'm still not really close to that.