Document toolboxDocument toolbox

Adding new properties and secrets to Synapse

versioncomment
20211109Added this table
20190610Add access via stack config
20180912Created

The purpose of this page is to explain the process of adding new secrets and properties to Synapse.

Properties can be used to set flags and values that should change when building on a different machine. This allows local builds to interact with separate databases, worker queues, etc. from production and staging builds. This can also make local builds more lightweight (by setting certain features to only enable in production). Secrets provide similar benefits, but additionally restrict access to critical information such as credentials.

Accessing a default value to a property or secret via the Stack Configuration

The easiest way to set the default value of a property or secret is to add it to the stack.properties file.

The stack.properties file is tracked in Git, so don't commit any secrets to this file!

Once added to stack.properties, add a getter method to the StackConfiguration interface in lib/stackConfiguration and according implementation(s).

If the property is not a secret, the StackConfiguration implementation may simply use ConfigurationProperties.getProperty() to retrieve the property.

If the property is a secret, you should use ConfigurationProperties.getDecryptedProperty() to retrieve the property, as retrieved secrets will be encrypted.

Storing secret values

We use AWS Secrets Manager to store and retrieve secrets in production. Thus, secrets in production must be retrieved from the Secrets Manager. To add a secret to the Secret Manager, give an AWS administrator (currently Xavier Schildwachter) the property name and value (or how to generate or retrieve the value).

In most circumstances, developers should not have access to secrets, so you should rarely be able to directly give an administrator the secret.


Overriding a property or a secret from the command line

If you want to be able to override a property or secret from the command line (for example, to load properties in a remote build), then you have to modify the integration-tests/pom.xml file

Under the org.codehaus.cargo plugin, you must add a tag of the following form (these tags should already exist and you should merely have to add the leaf tag with your property name):

integration-tests/pom.xml
<configuration>
   <!-- Container configuration -->
   <container>
   <systemProperties>
     <org.sagebionetworks.my.property.name>${org.sagebionetworks.my.property.name}</org.sagebionetworks.my.property.name>
   </systemProperties>
   </container>
<configuration>

This property can now be set using the -D command line flag, for example:

mvn cargo:run -Dorg.sagebionetworks.my.property.name=myPropertyValue

Note that if your value has spaces, you must wrap the entire -D flag in double quotes:

mvn cargo:run "-Dorg.sagebionetworks.my.property.name=my property value"

Adding a property to automated builds

If you want your property to be set on Jenkins, in addition to the above, add a line to docker_build.sh:

docker_build.sh
bash -c "mvn clean ${MVN_GOAL} \
# ... other properties
-Dorg.sagebionetworks.my.property.name=${org_sagebionetworks_my_property_name} \
# ... other properties

And configure the build on Jenkins to export the property value into org_sagebionetworks_my_property_name:

Jenkins Build Execute Shell
export user=pUser
export org_sagebionetworks_stack_iam_id=<id>
export org_sagebionetworks_stack_iam_key=<key>
export org_sagebionetworks_stackEncryptionKey=<key>
export rds_password=<pwd>
export github_token=<token>
export org_sagebionetworks_my_property_name=myValueForAutomatedBuilds
# other properties may be listed...

/var/lib/jenkins/workspace/${JOB_NAME}/jenkins_build.sh