Settings
Settings are used to provide any values that may differ between environments.
To access these values, reference the Settings
object, which is available in the global application namespace. Add settings keys and values to the ./config/settings.yml
file.
For instance, new integrations should have an enabled
boolean setting that will be set to false
in the production environment until the final review process for the integration is completed.
# config/settings.yml
my_external_service:
enabled: false
# config/routes.rb
...
# Check the settings to determine if the service is enabled
if Settings.my_external_service.enabled
resources :my_services
end
...
Settings in the development, staging, and production VA.gov environments
For settings in non-local environments, follow the steps outlined in the “Vets API Settings and Secrets” section of https://depo-platform-documentation.scrollhelp.site/developer-docs/vets-api-on-eks#VetsAPIonEKS-VetsAPISettingsandSecrets.
Overriding Settings
Often it may be useful to override settings in ./config/settings.yml
during development. Provide the new value to ./config/settings.local.yml
, and this value will be used instead of the default. The ./config/settings.local.yml
file is maintained locally, and should not be committed to git.
# config/settings.yml
my_external_service:
enabled: false
# config/settings.local.yml
my_external_service:
enabled: true
# config/routes.rb
...
if Settings.my_external_service.enabled
# Disabled by default, but available locally
resources :my_services
end
...
Secrets
Secret configuration settings, including internal IP addresses, access tokens, private keys, and passwords, are stored in AWS Parameter Store, and exposed to your integration as it's running on the deployed environment. If needed, reach out in #vfs-platform-support for assistance with uploading parameters to AWS. These settings may be accessed via the Settings
object available in the global application namespace.
You're most likely going to use this system to access credentials used to authenticate against VA services.
Provide sane defaults in config/settings.yml
that other developers can use locally, and which are safe to provide to the public. Contact the Platform team to arrange secure delivery and configuration of the settings that will be used in the development, staging, and production environments.
# config/settings.yml
my_exgternal_service:
secret: my-default-secret-value
key_path: ~/.certs/my_service_local.key
# config/settings.local.yml (installed through deployment process)
my_external_service:
secret: my-very-secret-value
key_path: /etc/ssl/private/keys/my_service_prod.key
# lib/my_integration/my_external_service/configuration.rb
module MyIntegration
module MyExternalService
class Configuration < Common::Client::Configuration::REST
...
def client_key
OpenSSL::PKey::RSA.new File.read(Settings.my_external_service.key_path)
end
end
end
end
# lib/my_integration/my_external_service/service.rb
# TODO: apply Settings.my_external_service.secret to headers for the service. Would be awesome to have a way to do this in the service configuration, or at least in an easier to understand way.
Help and feedback
Get help from the Platform Support Team in Slack.
Submit a feature idea to the Platform.