Hand a change to the other account's admin
When a move needs a permission in an account you do not run, Douklar shows the exact statement for that account's admin to apply.
Douklar holds one profile per account, and its worker relay needs no cross-account grant. Some moves still need a permission on the other side: a source bucket that another account's role must read, or a key in another account. Douklar does not apply those changes. It shows the exact statement, and the admin of that account applies it.
Where the statements appear
| Where | What it hands over |
|---|---|
| Sync preflight | Key policy and IAM statements when a KMS key check finds a permission missing |
| S3 Batch readiness | Source bucket policy changes the Batch role needs to read the source |
| Common moves, carve-out | A worked example for accounts that share no Organization and no owner |
A read that is denied shows as "unknown" and does not block the run. The statement names the permission so the other admin can grant it.
A source bucket another account reads
An S3 Batch job runs as a role in the destination account,
douklar-s3-batch-operations unless your deployment names another. Batch
readiness checks the source bucket policy; when the role cannot read the
source, it shows this statement for the source account's admin to merge.
Sample accounts and bucket; the Sid suffix is derived from the bucket and
the role:
{
"Sid": "BatchRoleRead1521f0b6bee729b0",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::444455556666:role/douklar-s3-batch-operations" },
"Action": [
"s3:GetBucketLocation",
"s3:ListBucket",
"s3:PutInventoryConfiguration",
"s3:GetObject",
"s3:GetObjectTagging",
"s3:GetObjectVersion",
"s3:GetObjectVersionTagging"
],
"Resource": [
"arn:aws:s3:::platform-prod-assets",
"arn:aws:s3:::platform-prod-assets/*"
]
}The worker relay reads as the source profile and writes as the destination profile, so it needs no change to the source bucket policy.
A key in another account
A KMS key in another account needs two statements: one in the key policy, in the account that owns the key, and one IAM statement for the principal that uses it. Key policy statement:
{
"Sid": "AllowDouklarMigrationAccount",
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::444455556666:root" },
"Action": ["kms:GenerateDataKey", "kms:Decrypt"],
"Resource": "*",
"Condition": { "StringEquals": { "kms:ViaService": "s3.us-east-1.amazonaws.com" } }
}For a source key, kms:Decrypt alone is enough.
Objects on the AWS managed key aws/s3 can be read only inside their own
account. For those, use the worker relay: it reads as the source account and
writes as the destination account. Preflight blocks the other routes when the
source profile can read the key; otherwise it shows a note naming the key.
When you choose a destination key
In Review you can choose a specific KMS key for the run. Paste the full
key ARN (arn:aws:kms:<region>:<account>:key/<key id>); aliases and bare key
IDs are refused, because AWS resolves them in the writer's account. The key
must be in the destination bucket's Region.
Next
- Preflight and Review: what preflight reads before a run.
- Common moves: carve-out or merger.