Permit Amazon Connect to have read-only access to one of my S3 buckets

Hello,

Amazon Connect does not allow you to edit the AWSServiceRoleForAmazonConnect prefixed service-linked role. After you create a service-linked role, you cannot change the name of the role because various entities might reference the role. However, you can edit the description of the role using IAM.

https://docs.aws.amazon.com/connect/latest/adminguide/connect-slr.html#edit-slr

Amazon Connect allows s3:GetObject, s3:DeleteObject, s3:GetBucketLocation, and GetBucketAcl for the S3 bucket specified for recorded conversations and also grants s3:PutObject, s3:PutObjectAcl, and s3:GetObjectAcl to the bucket specified for exported reports.

To grant S3 read only access to a bucket, you can try adding the necessary permissions directly to the S3 bucket policy, you enable Amazon Connect to have the required access without modifying the default service-linked role.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::account-id:role/service-role/AWSServiceRoleForAmazonConnect"
      },
      "Action": [
        "s3:GetObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::your-bucket-name",
        "arn:aws:s3:::your-bucket-name/*"
      ]
    }
  ]
}

What are you trying to achieve, (Ie what’s the use case here that requires a RO access to a bucket)

If the S3 bucket is in the same AWS account as the service-linked role you tried to modify without success, you can simply grant it whatever permissions you want in the S3 bucket policy.

Within an individual AWS account, the basic rule of thumb is that it suffices for access to be premitted either by the identity-based policies attached to the principal (IAM role or IAM user) or by the resource-based policy of the target resource, such as an S3 bucket (in which case the resource-based policy is called the bucket policy) or SQS queue. There are only two exceptions to this rule, which is that KMS key policies and IAM role trust policies (also called "assume role policies") deviate from this rule, but that's irrelevant in this case.

Even though you can never modify a service-linked role (SLR), you can always grant any SLR access to any resource in your account in the resource-based policy of the target resource. Additionally, for KMS keys (also probably not relevant in this case), a KMS grant can be created also for an SLR to allow it KMS access, regardless of what is or isn't permitted by the IAM policies attached to the SLR that you can't modify.

Only an explicit "deny" statement in the SLR's identity-based policies or its permissions boundary could impose a hard limit on what you can permit if resource-based policies within the same account, by explicitly denying it some access. No "allow" can ever overrule an explicit "deny". I haven't seen such explicit denies attached to the SLRs of any service so far, however.