Chapter 9. Forward to Amazon CloudWatch from STS-enabled clusters


You can forward logs to Amazon CloudWatch and Amazon S3 from STS-enabled clusters, including cross-account configurations using AssumeRole.

9.1. Create an AWS IAM role

Create an Amazon Web Services (AWS) IAM role that your service account can assume to securely access AWS resources.

The following procedure demonstrates creating an AWS IAM role by using the AWS CLI. You can also use the Cloud Credential Operator (CCO) utility ccoctl. Using the ccoctl utility creates many fields in the IAM role policy that are not required by the ClusterLogForwarder custom resource (CR). The CR ignores these extra fields. However, the ccoctl utility provides a convenient way for configuring IAM roles. For more information see Manual mode with short-term credentials for components.

Prerequisites

  • You have access to an Red Hat OpenShift Logging cluster with Security Token Service (STS) enabled and configured for AWS.
  • You have administrator access to the AWS account.
  • AWS CLI installed.

Procedure

  1. Create an IAM policy that grants permissions to write logs to CloudWatch.

    1. Create a file, for example cw-iam-role-policy.json, with the following content:

      {
          "Version": "2012-10-17",
          "Statement": [
              {
                  "Effect": "Allow",
                  "Action": [
                      "logs:PutLogEvents",
                      "logs:CreateLogGroup",
                      "logs:PutRetentionPolicy",
                      "logs:CreateLogStream",
                      "logs:DescribeLogGroups",
                      "logs:DescribeLogStreams"
                  ],
                  "Resource": "arn:aws:logs:*:*:*"
              }
          ]
      }
    2. Create the IAM policy based on the earlier policy definition by running the following command:

      $ aws iam create-policy \
          --policy-name cluster-logging-allow \
          --policy-document file://cw-iam-role-policy.json

      Note the Arn value of the created policy.

  2. Create a trust policy to allow the logging service account to assume an IAM role:

    1. Create a file, for example cw-trust-policy.json, with the following content:

      {
      "Version": "2012-10-17",
      "Statement": [
          {
              "Effect": "Allow",
              "Principal": {
                  "Federated": "arn:aws:iam::123456789012:oidc-provider/<OPENSHIFT_OIDC_PROVIDER_URL>"
              },
              "Action": "sts:AssumeRoleWithWebIdentity",
              "Condition": {
                  "StringEquals": {
                      "<OPENSHIFT_OIDC_PROVIDER_URL>:sub": "system:serviceaccount:openshift-logging:logcollector"
                  }
              }
          }
      ]
      }
  3. Create an IAM role based on the trust policy defined earlier by running the following command:

    $ aws iam create-role --role-name openshift-logger --assume-role-policy-document file://cw-trust-policy.json

    Note the Arn value of the created role.

  4. Attach the policy to the role by running the following command:

    $ aws iam put-role-policy \
          --role-name openshift-logger --policy-name cluster-logging-allow \
          --policy-document file://cw-role-policy.json

Verification

  • Verify the role and the permissions policy by running the following command:

    $ aws iam get-role --role-name openshift-logger

    Example output

    ROLE	arn:aws:iam::123456789012:role/openshift-logger
    ASSUMEROLEPOLICYDOCUMENT	2012-10-17
    STATEMENT	sts:AssumeRoleWithWebIdentity	Allow
    STRINGEQUALS	system:serviceaccount:openshift-logging:openshift-logger
    PRINCIPAL	arn:aws:iam::123456789012:oidc-provider/<OPENSHIFT_OIDC_PROVIDER_URL>

Create a secret for Amazon Web Services (AWS) Security Token Service (STS) from the configured AWS IAM role by using the oc create secret --from-literal command.

Prerequisites

  • You have created an AWS IAM role.
  • You have administrator access to Red Hat OpenShift Logging.

Procedure

  • In the CLI, enter the following to generate a secret for AWS:

    $ oc create secret generic sts-secret -n openshift-logging --from-literal=role_arn=arn:aws:iam::123456789012:role/openshift-logger

    Example Secret

    apiVersion: v1
    kind: Secret
    metadata:
      namespace: openshift-logging
      name: sts-secret
    stringData:
      role_arn: arn:aws:iam::123456789012:role/openshift-logger

You can forward logs from logging for Red Hat OpenShift deployed on clusters with Amazon Web Services (AWS) Security Token Service (STS)-enabled to Amazon CloudWatch. Amazon CloudWatch is a service that helps administrators observe and monitor resources and applications on AWS.

Prerequisites

  • Ensure that you installed the Red Hat OpenShift Logging Operator.
  • You have configured a credential secret.
  • You have administrator access to Red Hat OpenShift Logging.

Procedure

  • Create or update a ClusterLogForwarder custom resource (CR):

    apiVersion: observability.openshift.io/v1
    kind: ClusterLogForwarder
    metadata:
      name: <log_forwarder_name>
      namespace: openshift-logging
    spec:
      serviceAccount:
        name: <service_account_name>
      outputs:
       - name: cw-output
         type: cloudwatch
         cloudwatch:
           groupName: 'prefix-{.log_type||"none"}'
           region: us-east-2
           authentication:
               type: iamRole
             iamRole:
                 roleARN:
                 key: role_arn               secretName: sts-secret
               token:
                 from: serviceAccount
      pipelines:
        - name: to-cloudwatch
          inputRefs:
            - infrastructure
            - audit
            - application
          outputRefs:
            - cw-output
    serviceAccount.name
    Specify the name of your service account.
    outputs.name
    Specify a name for the output.
    type
    Specify the cloudwatch type.
    groupName
    Specify the group name for the log stream.
    region
    Specify the AWS region.
    iamRole
    Specify iamRole as the authentication type for STS.
    roleARN
    Specify the name of the secret and the key where you store the role_arn resource.
    token
    Specify the service account token to use for authentication. To use the projected service account token, use from: serviceAccount.
    inputRefs
    Specify which log types to forward by using the pipeline: application, infrastructure, or audit.
    outputRefs
    Specify the names of the output to use when forwarding logs with this pipeline.

9.4. Cross-account log forwarding with AssumeRole

You can forward logs to external AWS accounts by using the AWS Security Token Service (STS) AssumeRole functionality. Cross-account log forwarding enables centralized logging across many AWS accounts while maintaining security boundaries.

Cross-account log forwarding works as follows:

  1. Initial Authentication: The collector authenticates to the AWS account of your cluster using Identity and Access Management (IAM) roles or access keys.
  2. Role Assumption: After initial authentication, the collector assumes a role in the target AWS account.
  3. Log Forwarding: The collector forwards logs to CloudWatch or S3 bucket in the target account using credentials of the assumed role.

When using cross-account log forwarding, keep these security considerations in mind :

  • Use external IDs for cross-account role assumptions.

    External ID serves as an additional identifier.

    Note

    External IDs appear in CloudTrail logs and API responses. Therefore, they are not considered secrets.

    Take the following measures when creating external IDs:

    • They should be unique for each trust relationship.
    • They should be unpredictable and not based on public information.
  • Grant only the minimum required permissions to assumed roles.
  • Protect secrets containing role Amazon Resource Names (ARN) and tokens.
  • Monitor CloudTrail for AssumeRole activity.

9.5. Configure AWS IAM for cross-account access

You can configure AWS Identity Access Management (IAM) for cross-account access.

Prerequisites

  • You have administrator permissions.
  • You have created the target role and the target role has permissions to send data to CloudWatch or S3 outputs.
  • You have permissions to update the policy for the initial and the target role.

Procedure

  1. Create an initial account in your cluster account to assume the target role with the required permissions.

    The initial account can either be a user or an IAM role. This account assumes the target role.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": "sts:AssumeRole",
                "Resource": "arn:aws:iam::<target_aws_account_id>:role/target-logging-role"
            }
        ]
    }
  2. In your target role, create a trust policy and specify the initial cluster role, and optionally an external id.

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Principal": {
                    "AWS": "arn:aws:iam:::<role_or_user>/<role_name_or_user_name>"
                },
                "Action": "sts:AssumeRole",
                "Condition": {
                    "StringEquals": {
                        "sts:ExternalId": "<your_unique_external_id>"
                    }
                }
            }
        ]
    }

    Set the Principal.AWS field as follows:

    • If the initial account is a user, use the format:

      arn:aws:iam::<aws_account_id>:user/<user_name>

    • If the initial account is an IAM role, use the format:

      arn:aws:iam::<aws_account_id>:role/<role_name>

  3. Configure CloudWatch or S3 permissions in the target role depending on whether you want to forward logs to the CloudWatch or S3 output:

    CloudWatch permissions

    {
        "Version": "2012-10-17",
        "Statement": [
            {
                "Effect": "Allow",
                "Action": [
                    "logs:CreateLogGroup",
                    "logs:CreateLogStream",
                    "logs:PutLogEvents",
                    "logs:DescribeLogGroups",
                    "logs:DescribeLogStreams"
                ],
                "Resource": "*"
            }
        ]
    }

    S3 permissions

    {
        "Version": "2012-10-17",
        "Statement": [
            {
            "Sid": "AllowRoleToPutObjects",
            "Effect": "Allow",
            "Principal": {
                "AWS": "<assumerole_arn>"
            },
            "Action": [
                "s3:PutObject",
                "s3:PutObjectAcl"
            ],
            "Resource": [
                "arn:<aws_partition>:s3:::<s3_bucket>",
                "arn:<aws_partition>:s3:::<s3_bucket>/*"
            ]
            }
        ]
    }

The following example illustrates using cross-account AssumeRole field configuration when forwarding logs to CloudWatch.

ClusterLogForwarder resource with AssumeRole authentication

apiVersion: observability.openshift.io/v1
kind: ClusterLogForwarder
metadata:
  name: cross-account-example
  namespace: openshift-logging
spec:
  serviceAccount:
    name: my-sa
  outputs:
    - name: cw-cross-account
      type: cloudwatch
      cloudwatch:
        groupName: my-logs-{.log_type||"unknown"}
        region: us-east-1
        authentication:
          type: iamRole
          iamRole:
            roleARN:
              secretName: initial-role-secret
              key: role_arn
            token:
              from: serviceAccount
          # Cross-account assume role configuration
          assumeRole:
            roleARN:
              secretName: cross-account-secret
              key: assume_role_arn
            externalID: "my-unique-id-1234"
  pipelines:
    - name: cross-account-logs
      inputRefs:
        - application
      outputRefs:
        - cw-cross-account

  • authentication.assumeRole.roleARN: Reference to a secret containing the Amazon Resource Name (ARN) of the role to assume in the target account.
  • authentication.assumeRole.externalID: A string containing the external ID to enforce for assuming the role. This can add additional security by ensuring only entities with knowledge of the external ID can assume the role.

Session names for assumed role sessions are automatically generated by the Red Hat OpenShift Logging Operator to give meaningful identification in AWS CloudTrail logs for auditing purposes. The Operator generates session names by using cluster metadata as follows:

  • Primary format: {clusterId}-{clfName}-{outputName}.
  • Fallback format (if cluster metadata unavailable): output-{outputName}.
  • Always truncated to 64 characters maximum (AWS requirement).
  • Uses first 8 characters of cluster ID for uniqueness.

9.7. Cross-account log forwarding troubleshooting

The following table describes issues that you might experience with cross-account log forwarding and the steps that you can take to resolve the issues.

Table 9.1. Cross-account log forwarding issue and resolution
IssueTroubleshooting steps

Role Assumption Fails

  • Verify the trust relationship in the target account.
  • Verify that the external ID in the trust policy is an exact match with the one used in the ClusterLogForwarder Custom Resource (CR).
  • Ensure that the initial role has the sts:AssumeRole permission.

Permission Denied

  • Verify that the assumed role has the CloudWatch or S3 permissions.
  • Check the CloudWatch or s3 bucket resource policies.
  • Verify that region configuration matches in the initial and the target role.

Invalid role or user Amazon Resource Name (ARN)

  • Ensure that the role Amazon Resource Name (ARN) in the format:

    • arn:<aws_partition>:iam::<aws_account_id>:role/<role_name>
    • arn:<aws_partition>:iam::<aws_account_id>:user/<user_name>
  • Verify the role exists in the target account.
Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat Documentation

Legal Notice

Theme

© 2026 Red Hat
Back to top