The Identity Verification API (IDVA) API gateway uses Kong Gateway (OSS) to provide authentication and access to the rest of IDVA's microservices. IDVA uses a microservices architecture, and the API gateway serves as the entrypoint to those microservices.
The IDVA API Gateway aims to provide secure, unified access to IDVA microservices. Without the gateway, IDVA would be a segmented collection of related APIs, which sounds much less useful than a unified API providing identity validation services. The API Gateway has the following goals:
- Secure access to IDVA services
- Provide a single entrypoint to IDVA services
- Manage inbound/outbound traffic
The most up-to-date information about the CI/CD flows for this repo can be found in the GitHub workflows directory
If you plan to develop a new feature or add new code to this repo, you'll need the following:
You can test out kong features and configurations locally using the local Development steps, and use the Cloud.gov development steps when you're ready to test in cloud.gov.
Local Kong development can be done by:
-
Installing Kong via one the Kong's supported install methods.
-
Generate the Kong configuration file (kong.yaml) from the kong-config.yaml. This can be done by running
envsubst < kong-config.yaml > kong.yaml
after setting theENVIRONMENT_NAME
variable to one ofdev
,test
, orprod
. Note that unless deployed to cloud.gov, the urls of upstream services defined in kong.yaml will not be reachable from your local kong instance. The Kong decK CLI tool can still be used to manage validate the kong.yaml file by runningdeck validate --state kong.yaml
. Similarly, Kong can validate the kong.conf file by runningkong check ./kong.conf
-
Start your local Kong instance. Run
kong start -c ./kong.conf
to run your local Kong Gateway. Locally the only thing you should be able to do is validate that the correct configuration settings have been applied via the admin API.
To run a dev instance of the Kong service in cloud.gov, use the following steps:
-
Modify the manifest.yml file so that deployments don't step on other's dev instances by changing:
- The
name
of the application to something unique (perhaps including your username to prevent stranded test applications) - The entire
routes
section to justrandom-route: true
- The
-
Push your dev instance to cloud.gov by running
cf push --vars-file vars.yaml --var ENVIRONMENT_NAME=dev
.
If you still need direct access the Kong Admin API in cloud.gov, you can set up SSH connections the app as shown below:
# To enable/disable SSH. See https://docs.cloudfoundry.org/devguide/deploy-apps/ssh-apps.html
cf enable-ssh <app-name>
cf disable-ssh <app-name>
# Typical SSH access
cf ssh <app-name>
# Or to set up an SSH tunnel
cf ssh -N -T -L 8081:localhost:8081 <app-name>
See the Kong Admin API Documentation for details on usage.
💡 8081 is set as the Admin API port in manifest.yml, along with 8080 as the proxy port. These ports may vary during local development depending on your settings, but will be 8080/8081 within cloud.gov.
Configuration changes can be made by changing the kong-config.yaml
configuration file, and pushing those changes with the cf cli. Changes should be
performed locally to ensure correctness, and validated using the deck validate
command after generating the config file (see local development
for info on how).
This project is in the worldwide public domain. As stated in CONTRIBUTING:
This project is in the public domain within the United States, and copyright and related rights in the work worldwide are waived through the CC0 1.0 Universal public domain dedication.
All contributions to this project will be released under the CC0 dedication. By submitting a pull request, you are agreeing to comply with this waiver of copyright interest.