1. Application Settings Management – SSM Parameter Store
April 2018

2. What is the problem we are trying to solve?
Configuration settings stored in Octopus Deploy (web transforms)
Configuration settings stored in Team City
Secrets stored in Octopus Deploy (managed by infosec)
Secrets stored in Team City (managed by infosec)
Configuration settings stored in application source code/repositories
Applications have multiple environment settings baked in
Simple config changes have to go through the full life cycle – code change, check in, build, deploy everything to live.

3. What is SSM parameter store?
“AWS Systems Manager Parameter Store provides secure, hierarchical storage for configuration data management and secrets management. You can store data such as passwords, database strings, and license codes as parameter values. You can store values as plain text or encrypted data. You can then reference values by using the unique name that you specified when you created the parameter. Highly scalable, available, and durable, Parameter Store is backed by the AWS Cloud”

4. Why we choose SSM as the solution
One place to manage all secrets (easier for infosec)
One place to manage all application configuration
Simple Config changes won’t need a site deployment (*work required)
It’s a secure, scalable, hosted service
Control and audit access at granular levels (controlled by infosec)
Configure change notifications and trigger actions
Parameters can be tagged and secured (or secure by path)
Built into key AWS functions: EC2, ECS, Lambda, Cloudformation, CodeBuild, CodeDeploy…
Can also use AWS SDK for other tools: OD, TC
It’s FREE!

5. Quick demo of a working example
TeamCity Deployment
OLD vs NEW
Gamstop Consumer (node ecs app)
App loads configuration from ssm on startup
C# Test harness
Application hooks in a proxy on startup

6. Real world examples of its usage and what are the benefits we get from it.
Config change (e.g couchbase bucket) – can be done without a code change and a closely planned deployment through the environments. This will make future infrastructure changes more manageable as we build more and more services that need to communicate to each other.
Settings which change depending on the deployment environment can be pulled at application start-up time. This fits well with the containerisation pattern where we can bake a single deployment package which is suitable for all environments.
We can state with absolute certainty what a configuration value is or was at any given time. Currently, just seeing a value in TeamCity or OD requires further analysis of the build/deploy configuration to see if the value is even used.

7. What we haven't done
Built client libraries for everyone (currently node and c#)
Built in secret rotations (infosec road map)
Built in auto application configuration refresh (*app changes needed)
Migrated all applications (will take time)
Hardened the packages for DR
Better UI for managing settings (console is hard work)
Built Tombola procedures (clarify ownership of secrets)

8. Useful Links AWS Documentation Project Documentation Node Package
Project Documentation
Node Package
Node Example (Gamstop Batch Consumer)
Nuget Package
Nuget Example (UK Umbraco CMS)