Allow Cribl Search to access to your AWS data, by configuring an IAM role or user. See various trust policy examples.

Cribl Search uses Amazon Web Services (AWS) IAM to access and search your data in AWS. When creating an Amazon Dataset Provider in Cribl Search, you’ll need to provide it with credentials.

Access to AWS services is managed through AWS Identity and Access Management (IAM). You can grant access either at the IAM role level, or at the IAM user level using an access and secret key pair. Cribl recommends role-based access, as described below.

IAM User ​

You can use an IAM user’s access keys (access key IDs and secret access keys) to grant access to your data in AWS. If creating a new IAM user, give it Programmatic access so AWS assigns the user access keys.

IAM Role ​

Cribl recommends using IAM role-based access for increased security. An IAM role is similar to a user - it is an AWS identity with permission policies that determine what the identity can and cannot do in AWS. However, instead of passing IAM user credentials, here a user assumes a role and triggers AWS to dynamically generate temporary security credentials. With these temporary credentials, the user then accesses an AWS resource by its Amazon Resource Name (ARN).

For details about configuring the IAM role in the AWS console, see Create a role using custom trust policies. For details about using permissions policies to restrict an IAM role’s capabilities on AWS, see Permissions boundaries for IAM entities.

The process for granting access is:

1. Set up a new AWS IAM role in your account.

You need to either build the IAM role and policy using your own infrastructure-management solution (such as Terraform or CloudFormation), or else build it via the AWS console.

You can create a new role with Cribl’s trust policy instead of attaching it - see the next step.

2. Attach the trust policy, provided by Cribl, to the role in your account.

Modify your IAM role to include Cribl Search’s trust policy. You can do this with the AWS console, CLI, or API.

3. Add the appropriate permissions to your IAM role using an identity-based policy. For example, to allow access to an S3 bucket called cribl-search-data, you’d use the following sample permission policy:

   {
   "Version": "2012-10-17",
   "Statement": [{
      	"Effect": "Allow",
      	"Action": "s3:GetObject",
      	"Resource": "arn:aws:s3:::cribl-search-data/*"
      },
      {
      	"Effect": "Allow",
      	"Action": "s3:ListBucket",
      	"Resource": "arn:aws:s3:::cribl-search-data"
      }
   ]
   }

   Copy

4. Specify the IAM role’s ARN on an AWS Dataset Provider.

Trust Policy ​

Cribl Search builds a trust policy that creates a trust relationship between Cribl Search and a role in your AWS account. This policy controls and restricts access to only those resources to which you grant access. This trust relationship can be revoked at any time, without having to also revoke credentials (and thus, revoke access to the data).

The provided trust policy contains the AWS Role ARN and external ID of Cribl Search’s IAM role that you’ll need to trust. The policy allows Cribl Search to perform the sts:AssumeRole operation toward your external account.

The external ID is a custom string that you create to enhance authentication and authorization when accessing the S3 resource. The crucial requirement is to ensure that the strings match on both the Cribl Dataset Provider the and AWS trust policy.

The external ID must meet the length and character requirements that AWS specifies in IAM name requirements.

Example Trust Policy ​

Here is a basic trust policy - an anonymized version of the policy you can copy from your Dataset Provider modal’s Trust Policy button (when setting up the Authentication Method). See also the variations below the example.

In these examples, <TENANT_ID> and <EXTERNAL_ID> are anonymized placeholders:

• <TENANT_ID> is the Cribl AWS account ID for your organization. When you copy the trust policy from the Trust Policy button in your Dataset Provider modal, this value is automatically populated, so you do not need to look it up separately.
• <EXTERNAL_ID> is not pre-populated. Replace it with the value you entered in the External ID field of your Dataset Provider configuration.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<TENANT_ID>:role/search-exec-main"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<EXTERNAL_ID>"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<TENANT_ID>:role/search-exec-main"
      },
      "Action": "sts:TagSession"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<TENANT_ID>:role/search-exec-main"
      },
      "Action": "sts:SetSourceIdentity"
    }
  ]
}

Trust Policy with Multiple Workspaces ​

If you have configured multiple Workspaces, the default trust policy grants access only to your main Workspace. For other Workspaces, replace search-exec-main with search-exec-<WORKSPACE-ID>, where <WORKSPACE-ID> is the Workspace internal ID, not its display name.

To find a Workspace ID, select the Workspace name in the top navigation bar. In the modal that opens, the ID column lists the internal ID for each Workspace.

AWS does not support glob-style wildcards in IAM role ARN patterns within Principal elements. For example, arn:aws:iam::<TENANT_ID>:role/search-exec-* is not valid syntax. Add a separate set of three Principal statements (covering sts:AssumeRole, sts:TagSession, and sts:SetSourceIdentity) for each Workspace you need to authorize, substituting the correct Workspace ID in each.

Alternatively, you can use the fully open wildcard below, which allows any AWS principal and requires no per-Workspace changes. Use this approach only when your permission policies already tightly restrict what actions the assumed role can perform:

    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },

Trust Policy with ABAC Tagging ​

You can make your AssumeRole sessions more secure by adding Cribl’s VPCE (Virtual Private Cloud Endpoint) ID to your trust policy. This enables attribute-based access control (ABAC).

For an overview of how ABAC works on AWS, with links to further resources, see Define permissions based on attributes with ABAC authorization.

To set up ABAC on a supported Dataset Provider: After you enable the Apply ABAC source-ip tagging option, copy the adjacent VPCE ID to use later in this section. For convenience, we’ll start with the default trust policy shown above:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<TENANT_ID>:role/search-exec-main"
      },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": {
          "sts:ExternalId": "<EXTERNAL_ID>"
        }
      }
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<TENANT_ID>:role/search-exec-main"
      },
      "Action": "sts:TagSession"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<TENANT_ID>:role/search-exec-main"
      },
      "Action": "sts:SetSourceIdentity"
    }
  ]
}

Expand the Trust Policy ​

First, expand the "Action": "sts:TagSession" element by adding the sub-element shown below. Paste in the "${aws:SourceIp}" variable as-is. This enables passing Cribl Search’s source-ip value, making your sessions more secure by enforcing a condition that the source-ip tag must match the IP address requesting to assume the role:

   "Action": "sts:TagSession",
   "Condition": {
       "StringEquals": {
           "aws:RequestTag/source-ip": "${aws:SourceIp}"
       }
   }

Expand the Permission Policy ​

For the remaining steps, we’ll start with this anonymized default policy that you can copy from your Dataset Provider modal’s Permission Policy button (when setting up the Authentication Method).

{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action": "s3:GetObject",
        "Resource": ["arn:aws:s3:::<MY_S3_BUCKET>/*"]
      },
      {
        "Effect": "Allow",
        "Action": "s3:ListBucket",
        "Resource": ["arn:aws:s3:::<MY_S3_BUCKET>"]
      }
    ]
  }

Expand the s3:ListBucket element by adding the sub-element shown below. Replace vpce-<someVcpeId> with the VPCE IDs that you copied from your Dataset Provider’s config modal. You can include multiple VPCE IDs in the array:

      {
       "Effect": "Allow",
       "Action": "s3:ListBucket",
       "Resource": ["arn:aws:s3:::<MY_S3_BUCKET>"],
       "Condition": {
           "StringEquals": {
               "aws:SourceVpce": [
                   "vpce-<someVcpeId-1>",
                   "vpce-<someVcpeId-2>"
               ]
           }
       }
      }

Finally, copy the whole expanded s3:ListBucket element that you just modified. In the duplicated element shown below, paste in the "${aws:SourceIp}" variable as-is.

      {
       "Effect": "Allow",
       "Action": "s3:ListBucket",
       "Resource": ["arn:aws:s3:::<MY_S3_BUCKET>"],
       "Condition": {
           "StringEquals": {
               "aws:SourceVpce": [
                   "vpce-<someVcpeId-1>",
                   "vpce-<someVcpeId-2>"
               ]
           }
       }
      },
      {
       "Effect": "Allow",
       "Action": "s3:ListBucket",
    "Resource": ["arn:aws:s3:::<MY_S3_BUCKET>"],
       "Condition": {
           "StringEquals": {
               "aws:PrincipalTag/source-ip": "${aws:SourceIp}"
           }
       }
      }

Complete Permission Policy ​

To wrap up, you’ll end up with this expanded permission policy:

{
  "Version": "2012-10-17",
  "Statement": [
      {
        "Effect": "Allow",
        "Action": "s3:GetObject",
        "Resource": ["arn:aws:s3:::<MY_S3_BUCKET>/*"]
      },
      {
       "Effect": "Allow",
       "Action": "s3:ListBucket",
       "Resource": ["arn:aws:s3:::<MY_S3_BUCKET>"],
       "Condition": {
           "StringEquals": {
               "aws:SourceVpce": [
                   "vpce-<someVcpeId-1>",
                   "vpce-<someVcpeId-2>"
               ]
           }
       }
      },
      {
       "Effect": "Allow",
       "Action": "s3:ListBucket",
    "Resource": ["arn:aws:s3:::<MY_S3_BUCKET>"],
       "Condition": {
           "StringEquals": {
               "aws:PrincipalTag/source-ip": "${aws:SourceIp}"
           }
       }
      }
  ]
}