AWS Cloud Operations Blog

Introducing Parameter Store cross-account sharing

Earlier this year, AWS Systems Manager Parameter Store launched a feature that now allows you to share advanced parameters with other AWS accounts, enabling you to centrally manage your configuration data in a multi-account environment. Today, many customers have workloads in multiple AWS accounts that require shared, synchronized configuration data. Now, you can maintain a single source of truth for configuration data by sharing parameters with other accounts, removing the need to duplicate and synchronize data across accounts.

Parameter Store is a centralized data store for your configuration data, whether plain-text data such as database strings or encrypted data such as API keys. You can separate your configuration data from your code, and easily manage and update configurations across multiple workloads. Previously, parameters were only accessible by AWS account they were stored in. Now, by sharing parameters with other AWS accounts and AWS Organizations principals, you have an easy way for all of your workloads to access the configuration data they need, regardless of which account they are in. It doesn’t matter if the account is internal to your organization or external.

In this blog post, we will walk you through an example scenario where sharing parameters provides a simple, efficient solution for managing configuration data in multi-account environments.

To learn more about sharing parameters, visit the feature documentation.

Centralized Application Configuration.

Overview

Let us consider a scenario where you want to leverage Parameter Store cross-account sharing to provision lambda applications across distinct development environments (DEV, PROD), where the application will be provisioned with a specific application settings json, when running in a DEV account and different one when running in a PROD account. You can now keep the creation and maintenance of these keys separate from the resources that consume them; in this case the consumer being a lambda function. You are also now free from setting up cross account roles and writing extra boilerplate code to temporarily assume the role of the account where the parameter is hosted, creating clear separation of concerns.

The figure below highlights the placement of various accounts and the resources they contain. The lambda function in the DEV account will access the shared parameter /your-app/dev/appSettings and the function in the PROD account will access the shared parameter /your-app/prod/appSettings.

Fig 1: High level architecture

Fig 1: High level architecture

Prerequisites

For this walkthrough, you should have the following prerequisites:

  • Three individual AWS accounts (recommended)
    • A central-shared-services account where the shared parameters will be created.
    • Two target accounts to simulate DEV and PROD level access
  • AWS Resource Access Manager enabled in all three.
  • Knowledge on how to run AWS Lambda from the console.

Steps

To demonstrate how this works we will go through the steps outlined below in the same order for the DEV account.

1.   Create parameters for sharing using the console. In the Central-Shared-Services account, we will create two different parameters containing individual application settings for each environment. When creating the parameters be sure to select the Advanced Tier as this feature is only supported in the advanced tier and not the standard tier. Advanced tier parameters enable you to create more than 10,000 parameters, use larger parameter value size (up to 8 KB) and add policies to your parameter. More details on how to change from the standard to advanced tier mentioned here.

a. /your-app/dev/appSettings

{
  “env”: “dev”
}

b. /your-app/prod/appSettings

{
 “env”: “prod”
}

Fig 2: Advanced parameters created

Fig 2: Advanced parameters created.

2.      Create a Resource Share to share the parameters created above. For our example we will create a resource share for the DEV account using the following setup in the same account the parameters were created:

a.      Resource share name: shared-configuration-dev

b.      Resources: Parameter Store Advanced Parameters

This will populate the table below with all the advanced parameters that you created in this account. Check the checkboxes against the parameter names created in step #1a. We will use the parameter created in step #1b later.

c.      Selected resources: This should show a list of the parameters you selected in the prior step.

Fig 3: Section specifying the parameter to be shared with the DEV account

Fig 3: Section specifying the parameter to be shared with the DEV account

d.      Associate managed permissions: Keep the default options. You can choose to share with history if you set the dropdown using the AWSRAMPermissionSSMParameterReadOnlyWithHistory option.

fig-3.1 Associate managed permission

e.      Choose next.

f.       Principals:  Allow sharing for everyone.

Here you can select the principal type as AWS account and enter the account id for the DEV account. If all the accounts that you want to share to are under the same organization then you can slide the Display organizational structure radio button, to displays the organizations you want to share the parameters to. For the purpose of this walk through, we will select the specific account we want to share to, as seen the in the figure 4 below.

Fig 4: Section showing Grant access

Fig 4: Section showing Grant access

g.      Choose next.

h.      Choose the Create button on the review screen.

Your shared resources have been created and almost ready to be consumed in your DEV account. To know more about resource sharing head over to the documentation.

Let’s now access the resources that we shared. To do this, we will now head over to the account you designated as your DEV account.

3.      Once in your DEV account, go into Resource Access Manager service on the console and on the left panel under the Shared with me section, you should see a blurb calling out an open invitation that is pending against Resource shares link.

Choose that link to see the resource share that you created in the central account.

Fig 5: Table showing shared resources by name

Fig 5: Table showing shared resources by name

4.      Select the shared name, on shared name summary then choose the button that says Accept resource share.

Fig 6: Screen showing resource acceptance button

Fig 6: Screen showing resource acceptance button

After accepting the invitation your parameters are now ready to be consumed in your DEV account.

5.       Let’s test this using a Lambda function  in the assumed DEV account.

In the create function screen in the console select the following:

–        Author from scratch

–        Runtime as Python 3.12

–        Create a new role with basic Lambda permissions

Once the function is created, navigate to the code section of the function, clear out the default code and add the code snippet as below. Be sure to change the Region and account details in ARN.

import json
import boto3

def lambda_handler(event, context):

    ssm = boto3.client('ssm')
    parameter = ssm.get_parameter(Name='arn:aws:ssm:[REGION]:[YOUR-ACCOUNT]:parameter/your-app/dev/appSettings')
    ssm_val = parameter['Parameter']['Value']

    return {
        'statusCode': 200,
        'body': json.dumps('SSM Param value in this account: ' + ssm_val)
    }

In addition to the basic execution role, your lambda will need permissions to execute the call to the Parameter store. You can add these as an inline policy to the role created with the function. Here for the purpose of this example we use a scoped down, non-mutating policy as below.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
              "ssm:GetParameter",
              "ssm:GetParameters",
              "ssm:DescribeParameters"
            ],
            "Resource": "[parameter-arn]"
        }
    ]
}

Note: To access a shared parameter you must use the full ARN instead of just the parameter name.

ssm.get_parameter(Name='arn:aws:ssm:{region}:{account}:parameter/your-app/dev/appSettings ')

Running this code will give you the value stored to the shared parameter /your-app/dev/ appSettings in the central account. If you change the parameter and put PROD in place of DEV, you will get an AccessDeniedException. This is because our walk-through only included sharing the DEV parameter to the DEV account and not the PROD parameter. Your PROD appSettings is hereby secured.

To access the PROD appSettings, repeat the same steps as above for your PROD account. Now you have two different sets of parameters used in two different accounts being managed in one central account.

Cleaning up

To avoid incurring future charges, delete the resources created while following this example.

1.      Delete the resource share

2.      Delete the SSM Parameters

3.      Delete the Lambda functions created in the DEV and PROD accounts

Conclusion

In this blog post, we learned how we can set up configurations in a central shared services account and easily use them in the designated DEV and PROD accounts thereby maintaining a single source of truth for configuration data and removing the need to duplicate and synchronize data across accounts.

We can similarly apply the same learnings to  securely share parameters in multiple different accounts or all accounts across your organization, while reducing the extra work of managing cross account IAM roles and permissions.

Call to Action

To learn more about shared parameters, see Working with shared parameters.

For information about advanced-tier parameters, see Managing parameter tiers.

For advanced parameter pricing, see Systems Manager Pricing.

This feature is available in all AWS Regions, including the AWS GovCloud (US) Regions. For more information on services by region, see List of services available by Region.

Author bio

Neville Lewis

Neville Lewis is a Cloud Application Architect in AWS. He has extensive experience in application architecture design and is working on becoming a polyglot programmer while also delighting AWS customers at the same time. While off work, he likes hanging out with family, tinkering with gadgets, flying FPV drones and working on his guitar chops.

Tags:  AWS Systems Manager, Parameter Store, Management & Governance, Amazon Lambda