CODEWITHSUNDEEP
aws-cdkssm
Pedreiro
Pedreiro

Reputation: 1804

How to fetch SSM Parameters from two different accounts using AWS CDK

I have a scenario where I'm using CodePipeline to deploy my cdk project from a tools account to several environment accounts. The way my pipeline is deploying is by running cdk deploy from within a CodeBuild job.

My team has decided to use SSM Parameter Store to store configuration and we ended up with some parameters living in the environment account, for example the VPC_ID (resources/vpc/id) that I can read in deployment time => ssm.StringParameter.valueForStringParameter.

However, other parameters are living in the tools account, such as the Account Ids from my environment accounts (environment/nonprod/account/id) and other Global Config. I'm having trouble fetching those values.

At the moment, the only way I could think of was by using a step to read all those values in a previous step and loaded them into the context values.

Is there a more elegant approach for this problem? I was hoping I could specify in which account to get the SSM values from. Any ideas?

Thank you.

Upvotes: 10

Views: 8927

Answers (4)

justin1080602
justin1080602

Reputation: 123

This question is a year old, but a simpler method I found for retrieving parameters from your tools/deployment account is to specify them as env variables in your buildspec file. CodeBuild will always pull these from whatever account your job is running in (which in this question's scenario would be the tools account).

To pull parameters from your target environment accounts, it's best to use the CDK SSM approach suggested by the question author.

Upvotes: 1

John
John

Reputation: 11831

As part of your pipeline, I would add a preliminary step to execute a Lambda. That Lambda can then execute whatever queries you wish to obtain whatever metadata/config that is required. The output from that Lambda can then be passed in to the CodeBuild step.

e.g. within the Lambda:

export class ConfigFetcher {

  codepipeline = new AWS.CodePipeline();

  async fetchConfig(event: CodePipelineEvent, context : Context) : Promise<void> {

    // Retrieve the Job ID from the Lambda action
    const jobId = event['CodePipeline.job'].id;

    // now get your config by executing whatever queries you need, even cross-account, via the SDK
    // we assume that the answer is in the variable someValue
    const params = {
      jobId: jobId,
      outputVariables: {
        MY_CONFIG: someValue,
      },
    };
    // now tell CodePipeline you're done
    await this.codepipeline.putJobSuccessResult(params).promise().catch(err => {
      console.error('Error reporting build success to CodePipeline: ' + err);
      throw err;
    });
 
    // make sure you have some sort of catch wrapping the above to post a failure to CodePipeline
// ...
  }
}

const configFetcher = new ConfigFetcher();

exports.handler = async function fetchConfigMetadata(event: CodePipelineEvent, context : Context): Promise<void> {
  return configFetcher.fetchConfig(event, context);
};

Assuming that you create your pipeline using CDK, then your Lambda step will be created using something like this:

const fetcherAction = new LambdaInvokeAction({
  actionName: 'FetchConfigMetadata',
  lambda: configFetcher,
  variablesNamespace: 'ConfigMetadata',
});

Note the use of variablesNamespace: we need to refer to this later in order to retrieve the values from the Lambda's output and insert them as env variables into the CodeBuild environment.

Now our CodeBuild definition, again assuming we create using CDK:

new CodeBuildAction({
  // ...
  environmentVariables: {
    MY_CONFIG: {
      type: BuildEnvironmentVariableType.PLAINTEXT,
      value: '#{ConfigMetadata.MY_CONFIG}',
    },
  },

We can call the variable whatever we want within CodeBuild, but note that ConfigMetadata.MY_CONFIG needs to match the namespace and output value of the Lambda.

You can have your lambda do anything you want to retrieve whatever data it needs - it's just going to need to be given appropriate permissions to reach across into other AWS accounts if required, which you can do using role assumption. Using a Lambda as a pipeline step will be a LOT faster than using a CodeBuild step in the pipeline, plus it's easier to change: if you write your Lambda code in Typescript/JS or Python, you can even use the AWS console to do in-place edits whilst you test that it executes correctly.

Upvotes: 1

Alan Kis
Alan Kis

Reputation: 1910

As you already stated there is no native support for that. I am also using CodePipeline in cross-account deployments, so all the automation parameters or product specified parameters are stored in a secured account and CodePipeline deploys the resources using CloudFormation as an action provider.

Cross account resolution of SSM parameters isn't supported, so in the end, I had added an extra step (stage) in my CodePipeline, which is nothing else but a CodeBuild project, which runs a script in a containerized environment and scripts then "syncs" the parameters from the automation account to the destination account.

Upvotes: 2

Milan Gaty&#225;s
Milan Gaty&#225;s

Reputation: 2777

AFAIK there is no native way to achieve what you described. If there is way I'd like to know too. I believe you can use the CloudFormation custom resource baked by lambda for this purpose.

You can pass parameters to the lambda request and get information back from the lambda response.

See https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources-lambda.html, https://www.2ndwatch.com/blog/a-step-by-step-guide-on-using-aws-lambda-backed-custom-resources-with-amazon-cfts/ and https://docs.aws.amazon.com/cdk/api/latest/docs/custom-resources-readme.html for more information.

Upvotes: 1

Related Questions