Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add role based auth to CloudWatch exporter doc #3156

Merged
merged 12 commits into from
May 7, 2024
107 changes: 103 additions & 4 deletions use-timescale/metrics-logging/integrations.md
Original file line number Diff line number Diff line change
Expand Up @@ -40,6 +40,7 @@ Export telemetry data by:
1. In the Timescale console, navigate to `Integrations`.
1. Click `Create exporter`.
1. Choose the telemetry data type that you would like to send to a provider.
Datadog provider supports only metrics data type.
1. Under `Choose a provider`, choose `Datadog`.
1. Choose an AWS region for your exporter to live within Timescale. The
exporter is only available to database services in the same AWS region.
Expand Down Expand Up @@ -79,15 +80,111 @@ alt="Screenshot of the menu for adding a Datadog exporter" />
you're uncertain, use the default values. For more information on naming log
groups and logs streams, see [the AWS CloudWatch
docs][cloudwatch-log-naming].
1. Choose which authentication method you would like to use with your
exporter. We support CloudWatch credentials and IAM role. `CloudWatch
credentials` requires creating an IAM user in your AWS account and sharing
credentials of that user with Timescale. `IAM role` requires creating a
role with all necessary permissions and sharing only the role with
timescale.
<! -- At this place another branching should begin depending on what user
selected above. I'm not sure whether we need to represent this graphically by
adding tabs inside the existing tabs or just keep the options flat and explain
the alternatives in text. Writing it with text now and hope to get feedback on
this -->
<! -- Credentials case begin -- >
1. Enter your AWS credentials. To get your AWS keys, you need to create a new
Identity and Access Management (IAM) user in your AWS console. Make sure
your new user has restricted access to only Cloudwatch, and keep your keys
secret. For instructions, see the [AWS documentation][aws-access-keys].
<! -- Credentials case end -- >
<! -- IAM role case begin -- >
1. We are using [IRSA][irsa] in order to manage access from our cloud to
various resources within AWS. In order to grant permissions to a service
running in our AWS account to perform actions in your AWS account, the role
needs to be setup accordingly. Please refer to this [AWS
blog][cross-account-iam-roles] to understand the configuration elements
involved into that.
The URL that should be used depends on the region where the exporter is being created, it can be taken from this list:


| Region | Zone | Location | URL
|------------------|---------------|----------------|--------------------|
| `ap-southeast-1` | Asia Pacific | Singapore | `irsa-oidc-discovery-prod-ap-southeast-1.s3.ap-southeast-1.amazonaws.com`
| `ap-southeast-2` | Asia Pacific | Sydney | `irsa-oidc-discovery-prod-ap-southeast-2.s3.ap-southeast-2.amazonaws.com`
| `ap-northeast-1` | Asia Pacific | Tokyo | `irsa-oidc-discovery-prod-ap-northeast-1.s3.ap-northeast-1.amazonaws.com`
| `ca-central-1` | Canada | Central | `irsa-oidc-discovery-prod-ca-central-1.s3.ca-central-1.amazonaws.com`
| `eu-central-1` | Europe | Frankfurt | `irsa-oidc-discovery-prod-eu-central-1.s3.eu-central-1.amazonaws.com`
| `eu-west-1` | Europe | Ireland | `irsa-oidc-discovery-prod-eu-west-1.s3.eu-west-1.amazonaws.com`
| `eu-west-2` | Europe | London | `irsa-oidc-discovery-prod-eu-west-2.s3.eu-west-2.amazonaws.com`
| `sa-east-1` | South America | São Paulo | `irsa-oidc-discovery-prod-sa-east-1.s3.sa-east-1.amazonaws.com`
| `us-east-1` | United States | North Virginia | `irsa-oidc-discovery-prod.s3.us-east-1.amazonaws.com`
| `us-east-2` | United States | Ohio | `irsa-oidc-discovery-prod-us-east-2.s3.us-east-2.amazonaws.com`
| `us-west-2` | United States | Oregon | `irsa-oidc-discovery-prod-us-west-2.s3.us-west-2.amazonaws.com`

A Full example of a role called `my-exporter-role`, that has been configured following the [AWS
blog][cross-account-iam-roles] should look like:

- Permission Policy:
```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"logs:PutLogEvents",
"logs:CreateLogGroup",
"logs:CreateLogStream",
"logs:DescribeLogStreams",
"logs:DescribeLogGroups",
"logs:PutRetentionPolicy",
"xray:PutTraceSegments",
"xray:PutTelemetryRecords",
"xray:GetSamplingRules",
"xray:GetSamplingTargets",
"xray:GetSamplingStatisticSummaries",
"ssm:GetParameters"
],
"Resource": "*"
}
]
}
```

Trust Policy:
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@niconosenzo why do we call it trust policy here if it's a role?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 it was the trust policy that began in line 152 of my commit. Will double check though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if we want to be aligned with how AWS calls them in the blog, we need to call it a role with a trust policy

3. Create a role in the shared_content account that provides ReadOnlyAccess to all objects in pics bucket. Users federated by OIDC provider are allowed to assume this role.

 "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::shared_content_account_id:oidc-provider/oidc.eks.us-east-1.amazonaws.com/id/oidc-id"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "oidc.eks.us-east-1.amazonaws.com/id/oidc-id:aud": "sts.amazonaws.com"
        }
      }
    }
  ]
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TBH, for me it's always easier to split a role among permission policies and trust policies. But yeah we can call it a role if that makes more sense.

```json
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::12345678910:oidc-provider/irsa-oidc-discovery-prod.s3.us-east-1.amazonaws.com"
},
"Action": "sts:AssumeRoleWithWebIdentity",
"Condition": {
"StringEquals": {
"irsa-oidc-discovery-prod.s3.us-east-1.amazonaws.com:aud": "sts.amazonaws.com"
}
}
},
{
"Sid": "Statement1",
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::12345678910:role/my-exporter-role"
},
"Action": "sts:AssumeRole"
}
]
}
```
**Note** It's important to not forget adding the role itself as a trusted entity as shown above.

<! -- IAM role case end -- >

1. Select an AWS Region for your CloudWatch instance.
1. <Optional />Define an ARN role to use for uploading metrics or logs. Having a
dedicated role with only CloudWatch permissions is a recommended security
practice.
1. Click `Create exporter`.
2. Click `Create exporter`.

<Highlight type="warning">
AWS keys give access to your AWS services. To keep your AWS account secure,
Expand Down Expand Up @@ -199,6 +296,8 @@ Delete any data exporters that you no longer need.

[attach-exporter]: #attach-a-data-exporter-to-a-service
[aws-access-keys]: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_create.html#id_users_create_console
[irsa]: https://aws.amazon.com/blogs/opensource/introducing-fine-grained-iam-roles-service-accounts/
[cross-account-iam-roles]: https://aws.amazon.com/blogs/containers/cross-account-iam-roles-for-kubernetes-service-accounts/
[cloudwatch]: https://aws.amazon.com/cloudwatch/
[cloudwatch-docs]: https://docs.aws.amazon.com/cloudwatch/index.html
[cloudwatch-log-naming]: https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html
Expand Down