Add metrics aws sns policy logic #155
Conversation
|
I don't have any problem with this as long as @mikedorfman is also ok. For us early Cumulus adopters, we had a manual session with the Metrics team to set up their subscriptions. I was such a newbie to AWS I really didn't understand what they were doing. I don't remember them needing to add a policy, but it was pretty much magic to me at the time. |
|
I was looking through my old notes, the metrics team had me send them subscription requests from my SNS topics to their SQS queues. I guess that got around the IAM permissons. |
|
Interesting. These subscriptions work in our account, but their setup predates my time at NSIDC, so I'm not entirely sure how they were set up (likely similar to the process you describe above @lindsleycj). I have a task to completely tear down and rebuilt SIT coming up maybe next PI (as a DR test and to see what may have been applied manually in the console) - so this may become useful then. These changes look good to me, especially considering the default behavior is to not deploy the policy. |
|
Interesting, I wonder what the subtle difference is. Maybe they can make the subscription as code this way? |
This adds some missing outputs that are exposed by the cumulus module. I was attempting to add the policy generation for the metrics team to have SNS subscribe permissions. This change is optional to other DAACs but the cumulus resources that are created for reporting do not have the ability by default to be subscribed to by the metrics AWS accounts.
Some information can be found here https://wiki.earthdata.nasa.gov/display/METS/2.+(Tenant)+Shipping+Logs+To+Cloud+Metrics'+AWS+Account
The outputs I decided to refresh since I was in the account. I got the current list from here https://github.com/nasa/cumulus/blob/v15.0.3/tf-modules/cumulus/outputs.tf
This creates the ability for DAACs to add maturity specific accounts to the policy via the
metrics_es_aws_account_idvariable.