最近使用 CDK 常遇到有一個情境，就是開發 Construct 時，會使用到 lambda，然後 lambda 上需要有一些環境變數，而這些環境變數中不乏有敏感資料，如 GitHub Token、Slack token 等…，而 CDK 最終是 synth 成 CloudFormation，所以最終生成的 CloudFormation 中就要注意會不會曝露一些敏感資料，尤其在 GitHub Public Repository 中跑 CI 時(不論是 Travis CI or GitHub Actions)，如果不小心曝露敏感資料，是會有杯具的
原理
其實 CDK 官方文件 Get a value from the Systems Manager Parameter Store 寫的很清楚，只是有時候看過的文件也不一定都記的住，所以容易犯錯，犯錯沒關係，知道「為什麼犯錯」比較重要，也就是知道原理後，下次處理類似的問題就能在已理解下，避免再次犯錯
再來借一下 CDK App lifecycle 的圖片來說明一下
重點在 Synth 和 Deploy 階段是不一樣的，Synth 階段最主要的工作，就是組成 CloudFormation，供 Deployment 階段來部署，了解這個概念後，再來看 Get SSM Value 的文件就很清楚知道了
一般來說，都是在 deployment time 時，再取得 value 即可，才不會在 Synth 階段曝露在 CI 環境中，如以下範例程式碼
import * as ssm from '@aws-cdk/aws-ssm';
// Get latest version or specified version of plain string attribute
const latestStringToken = ssm.StringParameter.valueForStringParameter(
this, 'my-plain-parameter-name');
當然，也可能真的有必要在 Synth 階段取得，譬如想要在 Synth 階段去呼叫某些第三方 API，而又有資料想從 ssm 取得當做參數時，如下範例程式碼
import * as ssm from '@aws-cdk/aws-ssm';
const stringValue = ssm.StringParameter.valueFromLookup(this, 'my-plain-parameter-name');
針對不同場景，會有不同需求，總之，清楚自己在做什麼就好，避免像我之前看到 GitHub Actions 上印出 person token，差點嚇死，不過好在那是在 private repo 中跑的，所以沒事兒，萬一真的不小心發現 token 印在 public repo CI console 上，就快把該 token 刪掉就好，也希望大家都能愉快且安心的使用 CDK
