feat: Add ResourceShareAccepter CRD for accepting RAM share invita…

[rhysxevans]

Adds a ResourceShareInvitation CRD that lets a receiver account accept incoming AWS RAM share invitations declaratively, addressing aws-controllers-k8s/community#2786.

Per the reviewer feedback in #43 (comment), this PR has been reworked to use the standard ACK code-generation model rather than a hand-written resource manager.

Approach

Follows the same pattern route53resolver-controller#65 used for ResolverRuleAssociation: pick the noun the AWS API returns (rather than a verb), and map AWS lifecycle operations to ACK's Create/Read/Delete via generator.yaml.

• Kind: ResourceShareInvitation — matches the AWS API entity returned by GetResourceShareInvitations / AcceptResourceShareInvitation.
• Spec: the user provides resourceShareInvitationARN directly.
• Lifecycle:
  • Create → AcceptResourceShareInvitation
  • Read → GetResourceShareInvitations (filtered by the spec ARN)
  • Delete → DisassociateResourceShare
• Synced when: Status.Status == ACCEPTED.

Hand-written surface area

Everything else is generated. The only hand-written inputs are:

• generator.yaml: operation → resource mapping, field annotations (primary key / immutable / required, print columns), terminal_codes, 404 mapping (ResourceShareInvitationArnNotFoundException), synced.when.
• templates/hooks/resource_share_invitation/sdk_read_many_post_build_request.go.tpl: filters GetResourceShareInvitations by the spec ARN.
• templates/hooks/resource_share_invitation/sdk_delete_post_build_request.go.tpl: sets Principals from Status.ReceiverAccountID for DisassociateResourceShare.

Testing

• go build ./... and go test ./... pass.
• Generated artifacts produced via make build-controller SERVICE=ram + scripts/build-controller-release.sh ram against code-generator v0.59.1-7-g2970ca9 (same code-generator commit currently used by route53resolver-controller).
• E2E test reworked to use the new Kind and spec field; a malformed-ARN test exercises the terminal-error path via MalformedArnException.

Issue #, if available: aws-controllers-k8s/community#2786

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[ack-prow]

Hi @rhysxevans. Thanks for your PR.

I'm waiting for a aws-controllers-k8s member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[michaelhtm]

Thanks for the contribution @rhysxevans
Should we consider making ResourceShareAccepter a functionality of the ResourceShare CRD?
Similar to what we do with EKS AccessPolicies

[rhysxevans]

Hi

Thanks for reviewing, I am ultimately happy to take direction from you.

I do however feel that there may be a subtle difference

1. AccessPolicies are attached to AccessEntries, in the same account.
2. ResourceShare's are created in one account and shared to another (assuming not in the same org), and the ResourceShareAccepter is done in the "other" account. This is particularly relevant where the "sharer" is a 3rd party saas provider.

I don't know if my interpretation is in any way relevant though.

Let me know your thoughts

Thanks

[rhysxevans]

FYI: @michaelhtm I have created #44 as a response to your comment #43 (review)

[michaelhtm]

1. AccessPolicies are attached to AccessEntries, in the same account.
2. ResourceShare's are created in one account and shared to another (assuming not in the same org), and the ResourceShareAccepter is done in the "other" account. This is particularly relevant where the "sharer" is a 3rd party saas provider.

You are right, thanks for clarifying the differences.
After a closer look, i do see the need for an accepter, but i wonder if ACK is equipped to support this.
I noticed you have not used the code-generator.

Another quirk i see is, an Accepter is not necessarily a resource, so it feels weird to have a CRD for it, although i do see Terraform does support it

@a-hilaly @knottnt any thoughts?

[rhysxevans]

Hi, yep, apologies around not using the code generator.

Once we have a direction of travel, I will look at re-implementing via the code generator

[rhysxevans]

Hi

@michaelhtm @a-hilaly @knottnt any thoughts ?

[michaelhtm]

Hey @rhysxevans
All ACK controllers are generated by code-generator. This one seems like it wasn't. Can you try using generator.yaml to introduce the resource? You can use this PR as an example: aws-controllers-k8s/route53resolver-controller#65

[rhysxevans]

Hi @michaelhtm

Can you confirm which way you would like to go with the CRD. the way outlined in this PR (separate) or in the current CRD #44 ?

I can then look at the the code generator for the relevant solution ?

Thanks

[ack-prow]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rhysxevans
Once this PR has been reviewed and has the lgtm label, please assign a-hilaly for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[rhysxevans]

In

apiVersion: ram.services.k8s.aws/v1alpha1
kind: ResourceShareInvitation
metadata:
  name: test-ack
  namespace: default
spec:
  resourceShareInvitationARN: arn:aws:ram:eu-west-1:512345678910:resource-share-invitation/e014ac15-6db0-4bac-8545-6aase8db915cc

Out

apiVersion: ram.services.k8s.aws/v1alpha1
kind: ResourceShareInvitation
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"ram.services.k8s.aws/v1alpha1","kind":"ResourceShareInvitation","metadata":{"annotations":{},"name":"test-ack","namespace":"default"},"spec":{"resourceShareInvitationARN":"arn:aws:ram:eu-west-1:512345678910:resource-share-invitation/e014ac15-6db0-4bac-8545-6aase8db915cc"}}
  creationTimestamp: "2026-06-20T09:44:05Z"
  finalizers:
  - finalizers.ram.services.k8s.aws/ResourceShareInvitation
  generation: 1
  name: test-ack
  namespace: default
  resourceVersion: "2277"
  uid: f94f923c-618c-4802-8cd9-c49b9cae26bf
spec:
  resourceShareInvitationARN: arn:aws:ram:eu-west-1:512345678910:resource-share-invitation/e014ac15-6db0-4bac-8545-6aase8db915cc
status:
  ackResourceMetadata:
    arn: arn:aws:ram:eu-west-1:512345678910:resource-share-invitation/e014ac15-6db0-4bac-8545-6aase8db915cc
    ownerAccountID: "00012345678910"
    partition: aws
    region: eu-west-1
  conditions:
  - lastTransitionTime: "2026-06-20T09:54:28Z"
    message: Resource synced successfully
    reason: ""
    status: "True"
    type: ACK.ResourceSynced
  - lastTransitionTime: "2026-06-20T09:54:28Z"
    message: Resource synced successfully
    reason: ""
    status: "True"
    type: Ready
  invitationTimestamp: "2026-06-20T09:54:28Z"
  receiverAccountID: "00012345678910"
  resourceShareARN: arn:aws:ram:eu-west-1:512345678910:resource-share/e014ac15-6db0-4bac-8545-6aase8db915cc
  resourceShareName: test-ack
  senderAccountID: "512345678910"
  status: ACCEPTED

[HansG89]

Hi, just checking in on this one. Is it still actively being worked on, or blocked on something? We have a use case waiting on this and would be happy to help move it forward if useful. Thanks for the work here!

[michaelhtm]

Hey @HansG89 @rhysxevans
I don't think this is a CRD we can support in ACK.
ACK manages control plane resources. AcceptResourceShare feels more like a Dataplane operation (no resource is being created).
cc: @knottnt @a-hilaly

[HansG89]

Hi @michaelhtm

appreciate you taking another look at this.

Genuinely curious about the control-plane/dataplane distinction here, since route53resolver-controller ships two CRDs that look like the same shape as what's being proposed here: pure association/action resources with no independent AWS-native existence beyond the link itself.

From route53resolver-controller's generator.yaml (currently on main, not in ignore.resource_names):

operations:
  AssociateResolverRule:
    resource_name: ResolverRuleAssociation
    operation_type: Create
  DisassociateResolverRule:
    resource_name: ResolverRuleAssociation
    operation_type: Delete
  GetResolverRuleAssociation:
    resource_name: ResolverRuleAssociation
    operation_type: Read_One

ResolverRuleAssociation and ResolverQueryLogConfigAssociation are both live, shipped CRDs today, both modeling an associate/disassociate action rather than a resource with its own lifecycle independent of the association.

This is actually the exact pattern you pointed @rhysxevans toward back in June (route53resolver-controller#65) as the model to follow for this PR. Given that, would love to understand what makes AcceptResourceShareInvitation different enough to be dataplane while AssociateResolverRule counts as control-plane. Is it about mutability of existing state vs. creating a new association record, or something else? Happy to help narrow the distinction if there's a principle here that should also apply back to the Resolver associations.

[rhysxevans]

Hi, I have found another area where this sort of logic applies, account OU moves, https://docs.aws.amazon.com/cli/latest/reference/organizations/move-account.html, so it would be good to get some guidance.

[HansG89]

@a-hilaly @knottnt @michaelhtm, pinging directly for a decision on the CRD shape here. This has been open since February and stalled since the last exchange.

On the "dataplane operation" concern: route53resolver-controller ships two CRDs today that are structurally identical to what's proposed in this PR: an associate/disassociate action modeled as a CRD, with no independent resource lifecycle beyond the action itself.

# route53resolver-controller/generator.yaml (main, merged via #65)
AssociateResolverRule:
  resource_name: ResolverRuleAssociation
  operation_type: Create
DisassociateResolverRule:
  resource_name: ResolverRuleAssociation
  operation_type: Delete
GetResolverRuleAssociation:
  resource_name: ResolverRuleAssociation
  operation_type: Read_One

Same for ResolverQueryLogConfigAssociation (AssociateResolverQueryLogConfig / DisassociateResolverQueryLogConfig). Both are live, generated via generator.yaml, no hand rolled resource manager, same pattern this PR now follows (per @michaelhtm's June 4 suggestion to model it after route53resolver-controller#65).

If AcceptResourceShareInvitation is dataplane because "no resource is created," the same argument applies to AssociateResolverRule. It doesn't create a new AWS side entity either, it links two existing ones. I'd like to understand the distinguishing principle, since as is the two look like the same shape to me, and I want to apply whatever the answer is consistently rather than relitigate it later.

@rhysxevans also flagged a second case with the same shape: organizations:MoveAccount. No CRD exists for it in organizations-controller today, but it's another AWS API that's a pure state transition with no independent resource, worth keeping in mind if a general principle comes out of this discussion.

Could we get a direct yes or no on whether a standalone ResourceShareInvitation CRD (this PR) is acceptable, given the Resolver precedent above? And if the answer is no, rather than let this stall again, I'd propose adding the accept invitation capability as a field on the existing ResourceShare CRD instead (sketched in #44) as a fallback, happy to help drive that if it's the preferred direction. Either way, an explicit decision here unblocks a real use case waiting on this.