provider-aws
provider-aws copied to clipboard
Support structured fields for IAM policies
What problem are you facing?
Today the IAMPolicy
type supports a Document
string field for the IAM policy. This expects a json document for the policy definition. My use case is I would like to create IAM policy within a composition and have fields within the document patched based on other resources within the composition.
How could Crossplane help solve your problem?
https://github.com/crossplane/provider-aws/pull/289 for s3 bucket policy offers well defined policy fields which are serialized into the json document. IAMPolicy
should offer something similiar. The json string field Document
would still be preferred if non-empty, but otherwise a structured PolicyStatement
field could be used.
Example with document:
apiVersion: identity.aws.crossplane.io/v1alpha1
kind: IAMPolicy
metadata:
name: somepolicy
spec:
forProvider:
name: external-name
document: |
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "elastic-inference:Connect",
"Resource": "*"
}
]
}
providerRef:
name: example
reclaimPolicy: Delete
Example with statement:
apiVersion: identity.aws.crossplane.io/v1alpha1
kind: IAMPolicy
metadata:
name: somepolicy
spec:
forProvider:
name: external-name
statement:
- effect: "Allow"
action: elastic-inference:Connect
resource: "*"
providerRef:
name: example
reclaimPolicy: Delete
This would also help with https://github.com/crossplane/provider-aws/issues/212
@mcavoyk thanks for opening this! We have considered supporting both structured and unstructured simultaneously (with one taking precedence over the other) by having a field such as rawStatement
if folks want to copy paste their json from the console. How does this solution sound to you?
This seems like the same (or a similar) use case to https://github.com/crossplane/crossplane/issues/1603.
@mcavoyk thanks for opening this! We have considered supporting both structured and unstructured simultaneously (with one taking precedence over the other) by having a field such as
rawStatement
if folks want to copy paste their json from the console. How does this solution sound to you?
Yeah that is what I'm proposing with the issue, offering both json string field and a structured field, with json string taking precedence.
This seems like the same (or a similar) use case to crossplane/crossplane#1603.
It's definitely the same sort of use case, around trying to make IAM role for service account easier, but I think having a structured IAM Policy will solve other use cases as well, when a composition would like to create a resource and the policy for an application to access the resource. I don't think the tickets are exclusive in this case, having both would make compositions simpler for policies.
As these fields are not provided natively in the aws-go-sdk/iam it is not straight forward to implement this. However, it is already implemented in the terraform aws_iam_policy_document data source (related code). Can this help?
Hi there, people! Is anyone working on this right now? I'm interested in taking this, although I'm not familiar with the codebase. If this is free to work on I would love to try contributing to it. Thank you!
I don't, feel free to take it.
Hi @erickfaustino ! You might be able to reuse the same struct from Bucket Policy. In fact, having the policy struct in one place and letting many policy resources import it would be pretty nice!
Any updates here? I would really like to use this :)
bump
Bump, this would be quite useful. Is this being prioritised at all?
Another possibility would be to create a filter such as FromCompositionToComposition
so we could modify apply transforms to fields in the Composition directly. This would allow us to use Go string interpolation to work with Policy templates.
Crossplane does not currently have enough maintainers to address every issue and pull request. This issue has been automatically marked as stale
because it has had no activity in the last 90 days. It will be closed in 14 days if no further activity occurs. Leaving a comment starting with /fresh
will mark this issue as not stale.