aws-cdk-lib/aws-batch: grantSubmitJob option to allow submission of any job revision

[wbeardall]

Describe the feature

When granting permission to submit a job on a particular queue to a grantee, it would be very helpful to either default to granting permission to submit any job revision, or to have an option which allows submission of any job revision, or both. For example,

const myJob = new batch.EcsJobDefinition(this, 'MyJob', {...});
const myQueue = new batch.JobQueue(this, 'MyQueue', {...});

myJob.grantSubmitJob(myGrantee, myQueue, {allowedRevisions: [1,2,3]});
// or 
myJob.grantSubmitJob(myGrantee, myQueue, {allowAllRevisions: true});

Naturally, these illustrate the feature for an explicit option for allowing submission of any revision. The interface would not change if the underlying permissions were simply broadened by default, but this might be undesirable for some users.

Use Case

When granting permission to submit a job on a particular queue to a grantee, the current implementation grants permission only to the specific version of the job that is currently being defined by the CDK. For example, if I have a CDK stack containing

const myJob = new batch.EcsJobDefinition(this, 'MyJob', {...});
const myQueue = new batch.JobQueue(this, 'MyQueue', {...});

myJob.grantSubmitJob(myGrantee, myQueue);

then the generated policy item looks like

{
    "Action": "batch:SubmitJob",
    "Resource": [
        "arn:aws:batch:us-east-1:000000000000:job-queue/MyQueue",
        "arn:aws:batch:us-east-1:000000000000:job-definition/MyJob:1"
    ],
    "Effect": "Allow"
}

This means that if the grantee attempts to submit a job using

new SubmitJobCommand({
  jobDefinition: 'MyJob',
...
});

the submission will fail due to insufficient permissions. This is somewhat unintuitive, as I expect to be able to submit a job without specifying a revision name within my app, given that the revision mechanism is abstracted away within the CDK deployment process.

Proposed Solution

This can be achieved through simple tweaking of the batch.EcsJobDefinition.grantSubmitJob method. As an example, my current workaround is to simply replace the call with

iam.Grant.addToPrincipal({
    actions: ['batch:SubmitJob'],
    grantee: myGrantee,
    resourceArns: [
      `arn:aws:batch:${scope.region}:${scope.account}:job-definition/${jobDefinitionName}`,
      `arn:aws:batch:${scope.region}:${scope.account}:job-definition/${jobDefinitionName}:*`,
      jobQueue.jobQueueArn
    ],
  });

Other Information

No response

Acknowledgements

• I may be able to implement this feature request
• [] This feature might incur a breaking change (although if the underlying default permission is changed, this might be considered breaking in terms of security posture for some users)

CDK version used

2.185.0

Environment details (OS name and version, etc.)

MacOS 15.3

[pahud]

Issue Summary

The current implementation of grantSubmitJob() in EcsJobDefinition only grants permissions to submit jobs using a specific revision of a job definition. This is counterintuitive because users often want to submit jobs using the latest revision or any revision without specifying the revision number.

Root Cause

The issue is in the grantSubmitJob method implementation in ecs-job-definition.ts:

aws-cdk/packages/aws-cdk-lib/aws-batch/lib/ecs-job-definition.ts

Lines 114 to 120 in 2dc5d70

	public grantSubmitJob(identity: iam.IGrantable, queue: IJobQueue) {
	iam.Grant.addToPrincipal({
	actions: ['batch:SubmitJob'],
	grantee: identity,
	resourceArns: [this.jobDefinitionArn, queue.jobQueueArn],
	});
	}

The method uses this.jobDefinitionArn, which includes the specific revision number (e.g., arn:aws:batch:us-east-1:123456789012:job-definition/MyJob:1). This creates an overly restrictive IAM policy that only allows submitting jobs with that exact revision.

When users submit a job using the AWS SDK without specifying a revision:

new SubmitJobCommand({
  jobDefinition: 'MyJob',
  // ...
});

AWS Batch uses the latest revision by default, but the IAM policy doesn't allow this because it's scoped to a specific revision.

User's Current Workaround

Current workaround is to bypass grantSubmitJob and manually create a more permissive policy:

iam.Grant.addToPrincipal({
  actions: ['batch:SubmitJob'],
  grantee: myGrantee,
  resourceArns: [
    `arn:aws:batch:${scope.region}:${scope.account}:job-definition/${jobDefinitionName}`,
    `arn:aws:batch:${scope.region}:${scope.account}:job-definition/${jobDefinitionName}:*`,
    jobQueue.jobQueueArn
  ],
});

This grants permission to:

• The base job definition (without revision)
• All revisions of the job definition (with wildcard)
• The job queue

Proposed Solution

Update the grantSubmitJob method to either:

1. Default to allowing any revision
2. Add an option parameter to control permissions:

public grantSubmitJob(
  identity: iam.IGrantable, 
  queue: IJobQueue, 
  options?: { 
    allowedRevisions?: number[]; 
    allowAllRevisions?: boolean;
  }
)

The implementation would construct the appropriate resource ARN patterns based on the options provided.

Implementation Considerations

• Security impact: Changing the default behavior to be more permissive could be considered a breaking change in terms of security posture
• Backward compatibility: Adding options preserves existing behavior while providing flexibility
• Usability: The current behavior is unintuitive and requires workarounds

I recommend implementing the option-based approach, as it provides flexibility without introducing breaking changes in the default behavior.

Making this a p2 and we welcome PRs.