> For the complete documentation index, see [llms.txt](https://docs.impossiblecloud.com/impossible-cloud-help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.impossiblecloud.com/impossible-cloud-help/security/identity-access-management-iam/managing-policies/string-conditions-and-prefix.md).

# String Conditions and s3:prefix

String conditions let you restrict access based on the value of a string in the request context. The most useful pairing for S3 is a string operator on the `s3:prefix` context key, which scopes `s3:ListBucket` to a folder inside a bucket.

For IP-based conditions, see [Policy Conditions](/impossible-cloud-help/security/identity-access-management-iam/managing-policies/policy-conditions.md).

## When to use string conditions

Use a string condition on `s3:prefix` to:

* Limit a user to listing objects under a specific folder.
* Give each user a private folder inside a shared bucket using `${aws:username}`.
* Block listing of a sensitive sub-folder with an explicit `Deny`.

For the step-by-step how-to with copy-paste policies, see [Restrict an IAM user to a folder](/impossible-cloud-help/security/identity-access-management-iam/managing-policies/restrict-iam-user-to-a-folder.md).

## Supported string operators

| Operator                    | Match semantics                                                               |
| --------------------------- | ----------------------------------------------------------------------------- |
| `StringEquals`              | Exact match. Case-sensitive.                                                  |
| `StringNotEquals`           | Exact non-match. Case-sensitive.                                              |
| `StringEqualsIgnoreCase`    | Exact match. Case-insensitive.                                                |
| `StringNotEqualsIgnoreCase` | Exact non-match. Case-insensitive.                                            |
| `StringLike`                | Wildcards. `*` matches any run of characters, `?` matches a single character. |
| `StringNotLike`             | Wildcard non-match.                                                           |

Each operator takes a context key and one or more values. Wildcards are only interpreted in `StringLike` and `StringNotLike` patterns. The matcher treats the request value as a literal byte sequence: no URL decoding, no Unicode normalization, no path normalization.

### Example

```json
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "s3:ListBucket",
        "Resource": "arn:aws:s3:::my-bucket",
        "Condition": {
            "StringLike": { "s3:prefix": "team-data/projectA/*" }
        }
    }]
}
```

This statement allows `s3:ListBucket` only when the request's `--prefix` parameter starts with `team-data/projectA/`. Every other request is denied.

## Modifier suffix: ...IfExists

Append `IfExists` to any string operator to make the condition pass when the context key is absent:

* `StringEqualsIfExists`
* `StringLikeIfExists`
* `StringNotLikeIfExists`

With `IfExists`, a request that omits `--prefix` passes the condition. Without `IfExists`, the same request is denied because the context key is treated as missing.

```json
"Condition": {
    "StringLikeIfExists": { "s3:prefix": "team-data/projectA/*" }
}
```

## Set-operator prefixes: ForAllValues, ForAnyValue

Multi-valued context keys (currently rare for `s3:prefix`, common for future keys) are evaluated with set semantics:

* `ForAllValues:StringLike` - every value in the context must match at least one pattern.
* `ForAnyValue:StringLike` - at least one value in the context must match a pattern.

These prefixes attach to any string operator. Example:

```json
"Condition": {
    "ForAnyValue:StringLike": {
        "s3:prefix": ["team-data/projectA/*", "team-data/projectB/*"]
    }
}
```

{% hint style="warning" %}
**ForAllValues on an absent context key denies on Impossible Cloud.** The AWS specification says `ForAllValues:` is vacuously true when the context key is absent. Impossible Cloud's evaluator denies in that case as a defense-in-depth choice. If you write `ForAllValues:StringLike { s3:prefix: ... }` as your only Allow, requests without a `--prefix` will return 403 AccessDenied.
{% endhint %}

## Policy variables in condition values

Variables expand inside Condition values, not only inside Resource ARNs. The supported variable is:

| Variable          | Resolves to                                                                                                                                    |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| `${aws:username}` | The calling IAM user's full username. On Impossible Cloud this is the email address used to create the user (for example `alice@example.com`). |

The resolved value is treated as a literal string. Special characters such as `+`, `@`, and `.` round-trip without URL encoding.

### Example: per-user folder isolation

```json
{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Allow",
        "Action": "s3:ListBucket",
        "Resource": "arn:aws:s3:::my-bucket",
        "Condition": {
            "StringLike": { "s3:prefix": "user-data/${aws:username}/*" }
        }
    }]
}
```

Each user can list only their own folder under `user-data/<their-username>/`.

## The s3:prefix context key

`s3:prefix` is populated from the `prefix` query parameter on `ListObjectsV2`. The key is present when the client sends `--prefix <value>` with a non-empty value. The key is treated as absent when the client omits `--prefix` or sends `--prefix ""`.

`s3:prefix` is available on `s3:ListBucket` actions. The context key is **not** populated for `s3:ListBucketVersions` or `s3:ListMultipartUploads`. A policy using `StringLike` on `s3:prefix` for those actions denies even when the request prefix matches.

## Combining conditions

Multiple condition keys inside one `Condition` block are joined with AND. All must hold for the statement to apply.

```json
"Condition": {
    "IpAddress":  { "aws:SourceIp": "203.0.113.0/24" },
    "StringLike": { "s3:prefix":    "user-data/${aws:username}/*" }
}
```

This statement requires both the source IP and the prefix to match. Either failing denies the request.

Multiple statements in one policy union with OR for Allow, and explicit Deny wins over Allow. See [Restrict an IAM user to a folder](/impossible-cloud-help/security/identity-access-management-iam/managing-policies/restrict-iam-user-to-a-folder.md) for the canonical Allow + Deny pattern that blocks a sensitive sub-folder.

## Operators not yet evaluated

The following operators parse without an error but evaluate as always-false, so policies using them deny every request:

* Numeric operators: `NumericEquals`, `NumericNotEquals`, `NumericLessThan`, `NumericLessThanEquals`, `NumericGreaterThan`, `NumericGreaterThanEquals`
* Date operators: `DateEquals`, `DateNotEquals`, `DateLessThan`, `DateLessThanEquals`, `DateGreaterThan`, `DateGreaterThanEquals`
* Boolean operator: `Bool`
* ARN operators: `ArnEquals`, `ArnLike`
* Binary operator: `BinaryEquals`

If you need behavior that one of these would normally provide, rewrite the policy using `IpAddress` or one of the supported string operators.

## See also

* [Policy Conditions](/impossible-cloud-help/security/identity-access-management-iam/managing-policies/policy-conditions.md) - IP address conditions (`IpAddress`, `NotIpAddress`).
* [Restrict an IAM user to a folder](/impossible-cloud-help/security/identity-access-management-iam/managing-policies/restrict-iam-user-to-a-folder.md) - tutorial with copy-paste policies.
* [Types of IAM Policies](/impossible-cloud-help/security/identity-access-management-iam/types-of-iam-policies.md) - inline vs managed.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.impossiblecloud.com/impossible-cloud-help/security/identity-access-management-iam/managing-policies/string-conditions-and-prefix.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.