Support structured fields for IAM policies

[mcavoyk]

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?

#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

[mcavoyk]

This would also help with #212

[hasheddan]

@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?

[negz]

This seems like the same (or a similar) use case to crossplane/crossplane#1603.

[mcavoyk]

@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.

[Knappek]

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?

[erickfaustino]

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!

[Knappek]

I don't, feel free to take it.

[muvaf]

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!

[eloo]

Any updates here?
I would really like to use this :)

[kennedy]

bump

[dgozalo]

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.

[github-actions]

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.