cloudformation-coverage-roadmap
cloudformation-coverage-roadmap copied to clipboard
AWS::Glue::ResourcePolicy
1. Title
New resource: AWS::Glue::ResourcePolicy
2. Scope of request
Glue Resource Policies can be used to grant other AWS accounts access to an account's Glue Data Catalog, or to restrict access within the same account (Read Documentation).
These resource policies can be set using the API or the console (see API calls linked in the documentation), but this resource is not available in CloudFormation currently.
3. Expected behavior
Pretty straightforward, accept at least a policy document which would be used to create a new resource policy or update an existing one. I'm not entirely sure if the PolicyHashCondition
value would need to be user input, or if it would be logic internal to the operation of the resource.
On delete, would delete the resource policy, unless a Retain
DeletionPolicy was specified.
4. Suggest specific test cases
- Create a new resource policy, including a policy where the policy document contains intrinsic functions like a Ref or Fn::Sub
- Update an existing policy created in the same stack
- Update a policy resource although a resource policy was already defined
- Delete a resource policy
- Drift detection to see if the policy matches what is defined in the template
5. Helpful Links to speed up research and evaluation
See documentation link above
6. Category
Analytics (Glue)
This is needed for Lake Formation Tag Based Access Control.
When can this feature be expected? Luckily already exists for terraform aws provider https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/glue_resource_policy.
will be huge benefits for automation of cross accounts Athena usage of glue databases
When this feature can be expected? It exists in IaC tools like Pulumi.
Ref: https://www.pulumi.com/registry/packages/aws/api-docs/glue/resourcepolicy/
CDK implementation with CustomResource:
new AwsCustomResource(this, id, {
onUpdate: {
service: 'Glue',
action: 'putResourcePolicy',
parameters: {
PolicyInJson: JSON.stringify(
new PolicyDocument({
statements: dataCatalogPolicyStatements, // list of PolicyStatement
}),
),
},
physicalResourceId: PhysicalResourceId.of('glueDataCatalogPermissions'),
},
onDelete: {
service: 'Glue',
action: 'deleteResourcePolicy',
},
policy: AwsCustomResourcePolicy.fromSdkCalls({
resources: AwsCustomResourcePolicy.ANY_RESOURCE,
}),
})
You don't have to use the other parameters listed in CLI/SDK, this example is working fine for creating/updating/deleting the policies.
Much needed feature, when is this expected to be added ?
It seems absurd that this issue has been open for over 4 years without a solution. We have a mix of plain CF templates and CDK across our estate, and to implement a fairly straightforward procedure, we would need to migrate a whole repository onto CDK, only to then have to use a custom resource?
is there any progress on this request ?
FYI we having been using a custom resource to achieve this, but it will cause unexpected issues like when the policy is empty or a principle doesn't resolve correctly. This CDK construct feature is still very necessary, please Glue Service Team.
Am surprised this has not het been provided. This is something basic and should be supported by CFT. Voicing my vote for this feature!