diff --git a/packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md b/packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md index 102c858104884..250e946698e9f 100644 --- a/packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md +++ b/packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md @@ -90,6 +90,7 @@ Flags come in three types: | [@aws-cdk/aws-iam:oidcRejectUnauthorizedConnections](#aws-cdkaws-iamoidcrejectunauthorizedconnections) | When enabled, the default behaviour of OIDC provider will reject unauthorized connections | 2.177.0 | (fix) | | [@aws-cdk/core:enableAdditionalMetadataCollection](#aws-cdkcoreenableadditionalmetadatacollection) | When enabled, CDK will expand the scope of usage data collected to better inform CDK development and improve communication for security concerns and emerging issues. | 2.178.0 | (config) | | [@aws-cdk/aws-lambda:createNewPoliciesWithAddToRolePolicy](#aws-cdkaws-lambdacreatenewpolicieswithaddtorolepolicy) | When enabled, Lambda will create new inline policies with AddToRolePolicy instead of adding to the Default Policy Statement | 2.180.0 | (fix) | +| [@aws-cdk/aws-efs:defaultAllowClientMount](#aws-cdkaws-efsdefaultallowclientmount) |When enabled, EFS will allow clients to mount and access the filesystem by default | V2NEXT | (fix) | @@ -167,7 +168,8 @@ The following json shows the current recommended set of flags, as `cdk init` wou "@aws-cdk/aws-elasticloadbalancingV2:albDualstackWithoutPublicIpv4SecurityGroupRulesDefault": true, "@aws-cdk/aws-iam:oidcRejectUnauthorizedConnections": true, "@aws-cdk/core:enableAdditionalMetadataCollection": true, - "@aws-cdk/aws-lambda:createNewPoliciesWithAddToRolePolicy": true + "@aws-cdk/aws-lambda:createNewPoliciesWithAddToRolePolicy": true, + "@aws-cdk/aws-efs:defaultAllowClientMount": true } } ``` @@ -1021,10 +1023,10 @@ removing these ingress/egress rules in order to restrict access to the default s | (not in v1) | | | | 2.78.0 | `false` | `true` | -**Compatibility with old behavior:** +**Compatibility with old behavior:** To allow all ingress/egress traffic to the VPC default security group you can set the `restrictDefaultSecurityGroup: false`. - + ### @aws-cdk/aws-kms:aliasNameRef @@ -1082,10 +1084,10 @@ provided. | (not in v1) | | | | 2.88.0 | `false` | `true` | -**Compatibility with old behavior:** +**Compatibility with old behavior:** If backwards compatibility needs to be maintained due to an existing autoscaling group using a launch config, set this flag to false. - + ### @aws-cdk/aws-opensearchservice:enableOpensearchMultiAzWithStandby @@ -1603,7 +1605,7 @@ If the flag is set to false then a custom resource will be created when using `U In an ECS Cluster with `MachineImageType.AMAZON_LINUX_2`, the canContainersAccessInstanceRole=false option attempts to add commands to block containers from accessing IMDS. CDK cannot guarantee the correct execution of the feature in all platforms. Setting this feature flag -to true will ensure CDK does not attempt to implement IMDS blocking. By **end of 2025**, CDK will remove the +to true will ensure CDK does not attempt to implement IMDS blocking. By **end of 2025**, CDK will remove the IMDS blocking feature. See [Github discussion](https://github.com/aws/aws-cdk/discussions/32609) for more information. It is recommended to follow ECS documentation to block IMDS for your specific platform and cluster configuration. @@ -1622,8 +1624,8 @@ It is recommended to follow ECS documentation to block IMDS for your specific pl *When set to true along with canContainersAccessInstanceRole=false in ECS cluster, new updated commands will be added to UserData to block container accessing IMDS. **Applicable to Linux only. IMPORTANT: See [details.](#aws-cdkaws-ecsenableImdsBlockingDeprecatedFeature)*** (temporary) In an ECS Cluster with `MachineImageType.AMAZON_LINUX_2`, the canContainersAccessInstanceRole=false option attempts to add commands to block containers from -accessing IMDS. Set this flag to true in order to use new and updated commands. Please note that this -feature alone with this feature flag will be deprecated by **end of 2025** as CDK cannot +accessing IMDS. Set this flag to true in order to use new and updated commands. Please note that this +feature alone with this feature flag will be deprecated by **end of 2025** as CDK cannot guarantee the correct execution of the feature in all platforms. See [Github discussion](https://github.com/aws/aws-cdk/discussions/32609) for more information. It is recommended to follow ECS documentation to block IMDS for your specific platform and cluster configuration. @@ -1680,7 +1682,7 @@ thumbprints from unsecure connections. When this feature flag is enabled, CDK expands the scope of usage data collection to include the following: * L2 construct property keys - Collect which property keys you use from the L2 constructs in your app. This includes property keys nested in dictionary objects. - * L2 construct property values of BOOL and ENUM types - Collect property key values of only BOOL and ENUM types. All other types, such as string values or construct references will be redacted. + * L2 construct property values of BOOL and ENUM types - Collect property key values of only BOOL and ENUM types. All other types, such as string values or construct references will be redacted. * L2 construct method usage - Collection method name, parameter keys and parameter values of BOOL and ENUM type. @@ -1694,7 +1696,7 @@ When this feature flag is enabled, CDK expands the scope of usage data collectio *When enabled, Lambda will create new inline policies with AddToRolePolicy instead of adding to the Default Policy Statement* (fix) -When this feature flag is enabled, Lambda will create new inline policies with AddToRolePolicy. +When this feature flag is enabled, Lambda will create new inline policies with AddToRolePolicy. The purpose of this is to prevent lambda from creating a dependency on the Default Policy Statement. This solves an issue where a circular dependency could occur if adding lambda to something like a Cognito Trigger, then adding the User Pool to the lambda execution role permissions. @@ -1705,4 +1707,20 @@ This solves an issue where a circular dependency could occur if adding lambda to | 2.180.0 | `false` | `true` | +### @aws-cdk/aws-efs:defaultAllowClientMount + +*When enabled, EFS will allow clients to mount and access the filesystem by default* (fix) + +When this feature flag is enabled, EFS will add read-only, write, and root access permissions to clients +accessing the filesystem via mount target by default. Without this flag, only write and root access permissions are granted. + +This resolves an issue where clients could have permission to write to the filesystem but were unable to properly mount it, leading to access problems. +By automatically including the read-only permission alongside the existing write and root access permissions, clients can fully interact with the EFS resources as expected. + + +| Since | Default | Recommended | +| ----- | ----- | ----- | +| (not in v1) | | | +| V2NEXT | `false` | `true` | + diff --git a/packages/aws-cdk-lib/cx-api/README.md b/packages/aws-cdk-lib/cx-api/README.md index 4002764b11810..600e19c278891 100644 --- a/packages/aws-cdk-lib/cx-api/README.md +++ b/packages/aws-cdk-lib/cx-api/README.md @@ -615,7 +615,7 @@ _cdk.json_ * `@aws-cdk/aws-lambda:createNewPoliciesWithAddToRolePolicy` -When this feature flag is enabled, Lambda will create new inline policies with AddToRolePolicy. +When this feature flag is enabled, Lambda will create new inline policies with AddToRolePolicy. The purpose of this is to prevent lambda from creating a dependency on the Default Policy Statement. This solves an issue where a circular dependency could occur if adding lambda to something like a Cognito Trigger, then adding the User Pool to the lambda execution role permissions. @@ -627,4 +627,22 @@ _cdk.json_ "@aws-cdk/aws-lambda:createNewPoliciesWithAddToRolePolicy": true } } -``` \ No newline at end of file +``` + +* `@aws-cdk/aws-efs:defaultAllowClientMount` + +When this feature flag is enabled, EFS will add read-only, write, and root access permissions to clients +accessing the filesystem via mount target by default. Without this flag, only write and root access permissions are granted. + +This resolves an issue where clients could have permission to write to the filesystem but were unable to properly mount it, leading to access problems. +By automatically including the read-only permission alongside the existing write and root access permissions, clients can fully interact with the EFS resources as expected. + +_cdk.json_ + +```json +{ + "context": { + "@aws-cdk/aws-efs:defaultAllowClientMount": true + } +} +``` diff --git a/packages/aws-cdk-lib/cx-api/lib/features.ts b/packages/aws-cdk-lib/cx-api/lib/features.ts index a7696e67fc726..3d05c1c2d764f 100644 --- a/packages/aws-cdk-lib/cx-api/lib/features.ts +++ b/packages/aws-cdk-lib/cx-api/lib/features.ts @@ -1407,13 +1407,13 @@ export const FLAGS: Record = { type: FlagType.BugFix, summary: 'When enabled, EFS will allow clients to mount and access the filesystem by default', detailsMd: ` - When this feature flag is enabled, EFS will add MOUNT, WRITE, and ROOT_ACCESS permissions to clients + When this feature flag is enabled, EFS will add read-only, write, and root access permissions to clients accessing the filesystem via mount target by default. Without this flag, only WRITE and ROOT_ACCESS permissions are granted. This resolves an issue where clients could have permission to write to the filesystem but were unable to - properly mount it, leading to access problems. By automatically including the MOUNT permission alongside - the existing WRITE and ROOT_ACCESS permissions, clients can fully interact with the EFS resources as expected. + properly mount it, leading to access problems. By automatically including the read-only permission alongside + the existing write and root access permissions, clients can fully interact with the EFS resources as expected. `, introducedIn: { v2: 'V2NEXT' }, recommendedValue: true,