Skip to content

Commit

Permalink
chore: serverAccessLogsUseBucketPolicy flag was released in 2.60.0 (#…
Browse files Browse the repository at this point in the history
…25435)

The current file says it was released on 2.59.0, but that is incorrect.


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
  • Loading branch information
rix0rrr authored May 4, 2023
1 parent 366e2e8 commit aff7ff4
Show file tree
Hide file tree
Showing 3 changed files with 39 additions and 39 deletions.
36 changes: 18 additions & 18 deletions packages/@aws-cdk/cx-api/FEATURE_FLAGS.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,8 +42,8 @@ Flags come in three types:
| [@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker](#aws-cdkaws-ecsdisableexplicitdeploymentcontrollerforcircuitbreaker) | Avoid setting the "ECS" deployment controller when adding a circuit breaker | 2.51.0 | (fix) |
| [@aws-cdk/aws-events:eventsTargetQueueSameAccount](#aws-cdkaws-eventseventstargetqueuesameaccount) | Event Rules may only push to encrypted SQS queues in the same account | 2.51.0 | (fix) |
| [@aws-cdk/aws-iam:standardizedServicePrincipals](#aws-cdkaws-iamstandardizedserviceprincipals) | Use standardized (global) service principals everywhere | 2.51.0 | (fix) |
| [@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy](#aws-cdkaws-s3serveraccesslogsusebucketpolicy) | Use S3 Bucket Policy instead of ACLs for Server Access Logging | 2.59.0 | (fix) |
| [@aws-cdk/aws-iam:importedRoleStackSafeDefaultPolicyName](#aws-cdkaws-iamimportedrolestacksafedefaultpolicyname) | Enable this feature to by default create default policy names for imported roles that depend on the stack the role is in. | 2.60.0 | (fix) |
| [@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy](#aws-cdkaws-s3serveraccesslogsusebucketpolicy) | Use S3 Bucket Policy instead of ACLs for Server Access Logging | 2.60.0 | (fix) |
| [@aws-cdk/customresources:installLatestAwsSdkDefault](#aws-cdkcustomresourcesinstalllatestawssdkdefault) | Whether to install the latest SDK by default in AwsCustomResource | 2.60.0 | (default) |
| [@aws-cdk/aws-codedeploy:removeAlarmsFromDeploymentGroup](#aws-cdkaws-codedeployremovealarmsfromdeploymentgroup) | Remove CloudWatch alarms from deployment group | 2.65.0 | (fix) |
| [@aws-cdk/aws-rds:databaseProxyUniqueResourceName](#aws-cdkaws-rdsdatabaseproxyuniqueresourcename) | Use unique resource name for Database Proxy | 2.65.0 | (fix) |
Expand Down Expand Up @@ -780,35 +780,35 @@ This flag disables use of that exceptions database and always uses the global se
| 2.51.0 | `false` | `true` |


### @aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy

*Use S3 Bucket Policy instead of ACLs for Server Access Logging* (fix)
### @aws-cdk/aws-iam:importedRoleStackSafeDefaultPolicyName

Enable this feature flag to use S3 Bucket Policy for granting permission fo Server Access Logging
rather than using the canned `LogDeliveryWrite` ACL. ACLs do not work when Object Ownership is
enabled on the bucket.
*Enable this feature to by default create default policy names for imported roles that depend on the stack the role is in.* (fix)

This flag uses a Bucket Policy statement to allow Server Access Log delivery, following best
practices for S3.
Without this, importing the same role in multiple places could lead to the permissions given for one version of the imported role
to overwrite permissions given to the role at a different place where it was imported. This was due to all imported instances
of a role using the same default policy name.

@see https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html
This new implementation creates default policy names based on the constructs node path in their stack.


| Since | Default | Recommended |
| ----- | ----- | ----- |
| (not in v1) | | |
| 2.59.0 | `false` | `true` |
| 2.60.0 | `false` | `true` |


### @aws-cdk/aws-iam:importedRoleStackSafeDefaultPolicyName
### @aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy

*Enable this feature to by default create default policy names for imported roles that depend on the stack the role is in.* (fix)
*Use S3 Bucket Policy instead of ACLs for Server Access Logging* (fix)

Without this, importing the same role in multiple places could lead to the permissions given for one version of the imported role
to overwrite permissions given to the role at a different place where it was imported. This was due to all imported instances
of a role using the same default policy name.
Enable this feature flag to use S3 Bucket Policy for granting permission fo Server Access Logging
rather than using the canned `LogDeliveryWrite` ACL. ACLs do not work when Object Ownership is
enabled on the bucket.

This new implementation creates default policy names based on the constructs node path in their stack.
This flag uses a Bucket Policy statement to allow Server Access Log delivery, following best
practices for S3.

@see https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html


| Since | Default | Recommended |
Expand Down Expand Up @@ -907,7 +907,7 @@ according to the OS of the machine image.
*SecretTargetAttachments uses the ResourcePolicy of the attached Secret.* (fix)

Enable this feature flag to make SecretTargetAttachments use the ResourcePolicy of the attached Secret.
SecretTargetAttachments are created to connect a Secret to a target resource.
SecretTargetAttachments are created to connect a Secret to a target resource.
In CDK code, they behave like regular Secret and can be used as a stand-in in most situations.
Previously, adding to the ResourcePolicy of a SecretTargetAttachment did attempt to create a separate ResourcePolicy for the same Secret.
However Secrets can only have a single ResourcePolicy, causing the CloudFormation deployment to fail.
Expand Down
36 changes: 18 additions & 18 deletions packages/aws-cdk-lib/cx-api/FEATURE_FLAGS.md
Original file line number Diff line number Diff line change
Expand Up @@ -42,8 +42,8 @@ Flags come in three types:
| [@aws-cdk/aws-ecs:disableExplicitDeploymentControllerForCircuitBreaker](#aws-cdkaws-ecsdisableexplicitdeploymentcontrollerforcircuitbreaker) | Avoid setting the "ECS" deployment controller when adding a circuit breaker | 2.51.0 | (fix) |
| [@aws-cdk/aws-events:eventsTargetQueueSameAccount](#aws-cdkaws-eventseventstargetqueuesameaccount) | Event Rules may only push to encrypted SQS queues in the same account | 2.51.0 | (fix) |
| [@aws-cdk/aws-iam:standardizedServicePrincipals](#aws-cdkaws-iamstandardizedserviceprincipals) | Use standardized (global) service principals everywhere | 2.51.0 | (fix) |
| [@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy](#aws-cdkaws-s3serveraccesslogsusebucketpolicy) | Use S3 Bucket Policy instead of ACLs for Server Access Logging | 2.59.0 | (fix) |
| [@aws-cdk/aws-iam:importedRoleStackSafeDefaultPolicyName](#aws-cdkaws-iamimportedrolestacksafedefaultpolicyname) | Enable this feature to by default create default policy names for imported roles that depend on the stack the role is in. | 2.60.0 | (fix) |
| [@aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy](#aws-cdkaws-s3serveraccesslogsusebucketpolicy) | Use S3 Bucket Policy instead of ACLs for Server Access Logging | 2.60.0 | (fix) |
| [@aws-cdk/customresources:installLatestAwsSdkDefault](#aws-cdkcustomresourcesinstalllatestawssdkdefault) | Whether to install the latest SDK by default in AwsCustomResource | 2.60.0 | (default) |
| [@aws-cdk/aws-codedeploy:removeAlarmsFromDeploymentGroup](#aws-cdkaws-codedeployremovealarmsfromdeploymentgroup) | Remove CloudWatch alarms from deployment group | 2.65.0 | (fix) |
| [@aws-cdk/aws-rds:databaseProxyUniqueResourceName](#aws-cdkaws-rdsdatabaseproxyuniqueresourcename) | Use unique resource name for Database Proxy | 2.65.0 | (fix) |
Expand Down Expand Up @@ -780,35 +780,35 @@ This flag disables use of that exceptions database and always uses the global se
| 2.51.0 | `false` | `true` |


### @aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy

*Use S3 Bucket Policy instead of ACLs for Server Access Logging* (fix)
### @aws-cdk/aws-iam:importedRoleStackSafeDefaultPolicyName

Enable this feature flag to use S3 Bucket Policy for granting permission fo Server Access Logging
rather than using the canned `LogDeliveryWrite` ACL. ACLs do not work when Object Ownership is
enabled on the bucket.
*Enable this feature to by default create default policy names for imported roles that depend on the stack the role is in.* (fix)

This flag uses a Bucket Policy statement to allow Server Access Log delivery, following best
practices for S3.
Without this, importing the same role in multiple places could lead to the permissions given for one version of the imported role
to overwrite permissions given to the role at a different place where it was imported. This was due to all imported instances
of a role using the same default policy name.

@see https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html
This new implementation creates default policy names based on the constructs node path in their stack.


| Since | Default | Recommended |
| ----- | ----- | ----- |
| (not in v1) | | |
| 2.59.0 | `false` | `true` |
| 2.60.0 | `false` | `true` |


### @aws-cdk/aws-iam:importedRoleStackSafeDefaultPolicyName
### @aws-cdk/aws-s3:serverAccessLogsUseBucketPolicy

*Enable this feature to by default create default policy names for imported roles that depend on the stack the role is in.* (fix)
*Use S3 Bucket Policy instead of ACLs for Server Access Logging* (fix)

Without this, importing the same role in multiple places could lead to the permissions given for one version of the imported role
to overwrite permissions given to the role at a different place where it was imported. This was due to all imported instances
of a role using the same default policy name.
Enable this feature flag to use S3 Bucket Policy for granting permission fo Server Access Logging
rather than using the canned `LogDeliveryWrite` ACL. ACLs do not work when Object Ownership is
enabled on the bucket.

This new implementation creates default policy names based on the constructs node path in their stack.
This flag uses a Bucket Policy statement to allow Server Access Log delivery, following best
practices for S3.

@see https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html


| Since | Default | Recommended |
Expand Down Expand Up @@ -907,7 +907,7 @@ according to the OS of the machine image.
*SecretTargetAttachments uses the ResourcePolicy of the attached Secret.* (fix)

Enable this feature flag to make SecretTargetAttachments use the ResourcePolicy of the attached Secret.
SecretTargetAttachments are created to connect a Secret to a target resource.
SecretTargetAttachments are created to connect a Secret to a target resource.
In CDK code, they behave like regular Secret and can be used as a stand-in in most situations.
Previously, adding to the ResourcePolicy of a SecretTargetAttachment did attempt to create a separate ResourcePolicy for the same Secret.
However Secrets can only have a single ResourcePolicy, causing the CloudFormation deployment to fail.
Expand Down
6 changes: 3 additions & 3 deletions packages/aws-cdk-lib/cx-api/lib/features.ts
Original file line number Diff line number Diff line change
Expand Up @@ -601,7 +601,7 @@ export const FLAGS: Record<string, FlagInfo> = {
@see https://docs.aws.amazon.com/AmazonS3/latest/userguide/enable-server-access-logging.html
`,
introducedIn: { v2: '2.59.0' },
introducedIn: { v2: '2.60.0' },
recommendedValue: true,
},

Expand Down Expand Up @@ -700,7 +700,7 @@ export const FLAGS: Record<string, FlagInfo> = {
summary: 'SecretTargetAttachments uses the ResourcePolicy of the attached Secret.',
detailsMd: `
Enable this feature flag to make SecretTargetAttachments use the ResourcePolicy of the attached Secret.
SecretTargetAttachments are created to connect a Secret to a target resource.
SecretTargetAttachments are created to connect a Secret to a target resource.
In CDK code, they behave like regular Secret and can be used as a stand-in in most situations.
Previously, adding to the ResourcePolicy of a SecretTargetAttachment did attempt to create a separate ResourcePolicy for the same Secret.
However Secrets can only have a single ResourcePolicy, causing the CloudFormation deployment to fail.
Expand Down Expand Up @@ -773,7 +773,7 @@ export const FLAGS: Record<string, FlagInfo> = {
can set the \`restrictDefaultSecurityGroup: false\`.
`,
},

//////////////////////////////////////////////////////////////////////
[APIGATEWAY_REQUEST_VALIDATOR_UNIQUE_ID]: {
type: FlagType.BugFix,
Expand Down

0 comments on commit aff7ff4

Please sign in to comment.