New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECS Secrets from SSM ParamStore exceeds IAM Policy size #8435
Comments
As a workaround you can always pass |
I've come across a similar issue, I found that when using CDK could make this better by adding an optional flag to disable autocreation of the additional IAM statements. As a workaround you can do the following:
|
Guys i had the same problem, when using an existing role, until i found the option mutable: Role.fromRoleArn(this, 'ECSTaskExecutionRole', 'MyExecutionRoleArn', { mutable: false }), |
@rix0rrr Would it take significant work to group the ssm secrets into one statement |
I've hit this too with around 40-50 secrets. The workarounds proposed don't seem to work for me for C# (trying to inherit Does anyone have a reliable workaround at the moment? |
I've managed to get a workaround working as expected for me in C#, for anyone else interested: When assigning the list of using EcsSecret = Amazon.CDK.AWS.ECS.Secret;
/// <summary>
/// Wrapper class that causes GrantRead() to do nothing
/// </summary>
class NoOpGrantReadSecret : EcsSecret
{
readonly EcsSecret _secretImplementation;
public NoOpGrantReadSecret(EcsSecret secretImplementation)
{
_secretImplementation = secretImplementation;
}
public override Grant GrantRead(IGrantable grantee)
{
// No Op
return Grant.Drop(grantee, "ignored");
}
public override string Arn => _secretImplementation.Arn;
public override bool? HasField => _secretImplementation.HasField;
} Example: var ecsService = new ApplicationLoadBalancedFargateService(..., new ApplicationLoadBalancedFargateServiceProps {
TaskImageOptions = new ApplicationLoadBalancedTaskImageOptions {
...,
Secrets = existingSecrets.ToDictionary(x => x.Key, x => (EcsSecret) new NoOpGrantReadSecret(x.Value))
}
}) That removes all the individual grants, but now we need to add them back in a wildcard read grant: const string ParamNamePrefix = "/your/ssm/param/hierarchy/*";
ecsService.TaskDefinition.ExecutionRole.AddToPrincipalPolicy(new PolicyStatement(new PolicyStatementProps
{
Effect = Effect.ALLOW,
Actions = new[] { "ssm:DescribeParameters", "ssm:GetParameter", "ssm:GetParameterHistory", "ssm:GetParameters" },
Resources = new[] { $"arn:aws:ssm:{props.Env!.Region}:{props.Env.Account}:parameter/{ParamNamePrefix}" }
})
); |
@Plasma thx a lot for your example. It is working for Java too. public class NoOpGrantReadSecret extends Secret {
private final Secret secretImplementation;
public NoOpGrantReadSecret(Secret secretImplementation) {
this.secretImplementation = secretImplementation;
}
@Override
public @NotNull Grant grantRead(@NotNull IGrantable grantee) {
return Grant.drop(grantee, "ignored");
}
@Override
public @NotNull String getArn() {
return secretImplementation.getArn();
}
@Override
public @Nullable Boolean getHasField() {
return secretImplementation.getHasField();
}
} Call: final Map<String, Secret> secretVariables = new HashMap<>();
var secret = Secret.fromSsmParameter(StringParameter.fromSecureStringParameterAttributes(
this,
"service-parameter-name",
SecureStringParameterAttributes.builder()
.parameterName(serviceSecrets.get("/path/to/ssm"))
.version(1)
.build()
));
secretVariables.put("ENV_VAR_NAME",new NoOpGrantReadSecret(secret));
var ssmReadOnlyPolicy = PolicyStatement.Builder.create()
.actions(Arrays.asList("ssm:Describe*", "ssm:Get*", "ssm:List*"))
.resources(Collections.singletonList("*"))
.build();
final TaskDefinition taskDefinition = TaskDefinition.Builder.create().build();
taskDefinition.addToExecutionRolePolicy(ssmReadOnlyPolicy);
ContainerDefinitionOptions containerDefinitionOptions = ContainerDefinitionOptions.builder()
.secrets(secretVariables)
.build(); |
There was a project completed last year to reduce the size of IAM policies across the board. See the tracking issue for more detail #19276. I believe this should be resolved. Please create a new issue if you continue to experience this issue. |
|
I'm unable to deploy my stack that makes use of ECS Secrets. I'm trying to use 58 ECS Secrets (current hard limit is 60) but how CDK is currently writing the IAM Policy for the Execution Role I'm hitting a limit with the IAM Policy.
The limit is being hit because CDK is adding a statement to the policy per parameter which creates a lot of duplication within the statement.
Reproduction Steps
Sorry, I don't have a stack that I can share.
Error Log
Maximum policy size of 10240 bytes exceeded for role
Environment
Other
My ideal solution would be an additional parameter for
ecs.Secret.fromSsmParameter
that gives the option to skip the grant. My stack already appends a Managed Policy to the Execution Role that has all of the access necessary for my application to pull the parameters.A more immediate option would be to group all of the SSM parameter grants into a single statement to dramatically reduce the duplication of the
Action
statements 60 timesThis is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: