Application Settings Management – SSM Parameter Store April 2018

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.

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” https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html

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!

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

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.

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)

Useful Links AWS Documentation Project Documentation Node Package https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-paramstore.html Project Documentation https://tombola.atlassian.net/wiki/spaces/PROJ/pages/284819841/Proof+of+Concept+Proposal Node Package https://github.com/tombolaltd/tombola.platform.node.packages/tree/master/arcade-platform-config Node Example (Gamstop Batch Consumer) https://github.com/tombolaltd/tombola.gamstop/blob/master/consumer/task.js Nuget Package https://github.com/tombolaltd/tombola.parameterstore.client Nuget Example (UK Umbraco CMS) https://github.com/tombolaltd/Tombola.CMS.Umbraco/blob/arcade/PU-7135-ssm_config/src/Tombola.Umbraco.Extensions/Application/TombolaWebBootManager.cs#L19