Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: AddClientIDToOpenIDConnectProvider #4460

Open
yambottle opened this issue Sep 13, 2024 · 4 comments
Open

Feature Request: AddClientIDToOpenIDConnectProvider #4460

yambottle opened this issue Sep 13, 2024 · 4 comments
Labels
awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). kind/enhancement Improvements or new features kind/question Questions about existing features

Comments

@yambottle
Copy link

Hi there,
I'm looking for a feature to add or attach new Client ID/Audience to an existing OIDC provider API doc

@pulumi-bot pulumi-bot added the needs-triage Needs attention from the triage team label Sep 13, 2024
@corymhall
Copy link
Contributor

@yambottle you should be able to add a new client to an OpenIDConnectProvider using the OpenIdConnectProvider resource.

If you are not currently managing the OpenIdConnectProvider you can import the resource.

@corymhall corymhall added awaiting-feedback Blocked on input from the author and removed needs-triage Needs attention from the triage team labels Sep 16, 2024
@yambottle
Copy link
Author

Hi @corymhall ,
Thanks for your response!
I might have a different use case of Pulumi project/stack abstraction here:

- organization_aws_account # Pulumi Project 1
- - org_iam.py # add OIDC provider
- - ...... # other org level infra
- - Pulumi.yaml
- - Pulumi.orgA.yaml
- - Pulumi.orgB.yaml

- team # Pulumi Project 2
- - team_iam.py # add audience/client_id
- - ...... # other team level infra
- - Pulumi.yaml
- - Pulumi.orgA_team1.yaml
- - Pulumi.orgA_team2.yaml
- - Pulumi.orgB_team1.yaml
- - Pulumi.orgB_team2.yaml

I have two Pulumi projects, the first one provisions organizational infra and each organization has a different AWS account; the second one provisions infra for each team within its organizational AWS account, and in my case, each team has a different client_id, but they need to have the same OIDC provider. With only OpenIdConnectProvider resource, I can only think of a solution that org_iam.py creates an OIDC provider and then team_iam.py gets the existing OIDC provider and then recreates/updates the existing OIDC provider with an updated client_id_list. However, this leads me to a 'resource exists' error.

My solution

  • Create the OIDC provider in org_iam.py
def create_oidc_idp():
  url = "xxx"
  account_id = aws.get_caller_identity().account_id
  
  try:
    existing_provider = aws.iam.get_open_id_connect_provider(arn=f"arn:aws:iam::{account_id}:oidc-provider/{url}")
  except:
    existing_provider = None
  # just in case to call pulumi up later after a new client_id been added
  if existing_provider:
    provider = aws.iam.OpenIdConnectProvider(
      "xxx",
      url=f"https://{existing_provider.url}",
      client_id_lists=existing_provider.client_id_lists,
      thumbprint_lists=existing_provider.thumbprint_lists
    )
  # initial creation
  else:
    provider = aws.iam.OpenIdConnectProvider(
      "xxx",
      url=f"https://{url}",
      client_id_lists=[],
      thumbprint_lists=["xxx"]
    )

# pulumi up --stack orgA
  • Add audience in team_iam.py
def add_audience_to_oidc_provider(client_id: str):
    url = "xxx"
    account_id = aws.get_caller_identity().account_id

    # if OIDC provider created and research_project provisioning adds client_id as audiences,
    # need to update the existing OIDC provider
    try:
      existing_provider = aws.iam.get_open_id_connect_provider(arn=f"arn:aws:iam::{account_id}:oidc-provider/{url}")
    except:
      raise Exception("OIDC provider not found")
    if existing_provider:
      existing_provider.client_id_lists.append(client_id)
      provider = aws.iam.OpenIdConnectProvider(
        "xxx",
        url=f"https://{existing_provider.url}",
        client_id_lists=existing_provider.client_id_lists,
        thumbprint_lists=existing_provider.thumbprint_lists
      )

# pulumi up --stack orgA_team1 -> 'resource exists' error
# pulumi up --stack orgA_team2 -> 'resource exists' error

Is there anything incorrect with how I deal with this? If not, I was thinking adding a function addClientIDToOpenIDConnectProvider or a resource ClientIDAttachment would be more logically straight forward to understand based on my Pulumi project/stack design. Or maybe there could be a better project/stack design for me, please let me know.

@pulumi-bot pulumi-bot added needs-triage Needs attention from the triage team and removed awaiting-feedback Blocked on input from the author labels Sep 16, 2024
@mjeffryes mjeffryes added the kind/question Questions about existing features label Sep 16, 2024
@corymhall
Copy link
Contributor

@yambottle thanks for the additional details. In these types of cases what I've done in the past is continue to centrally manage the OpenIdConnectProvider resource. If these projects are managed in different repos for example, the team that creates a new client_id would create a PR against the org repo to add their client to the provider.

If that doesn't work for your use case and you do need to be able to modify the OpenIdConnectProvider in different projects then I can see where a new resource would be useful. You would need to create a feature request in the terraform-provider-aws repo and see if they would be open to creating this additional resource.

@yambottle
Copy link
Author

@corymhall Thanks! Just created a request. For a temporary walk-around, I'll use boto3 add_client_id_to_open_id_connect_provider in the downstream script for now.

@pulumi-bot pulumi-bot added needs-triage Needs attention from the triage team and removed awaiting-feedback Blocked on input from the author labels Sep 16, 2024
@corymhall corymhall added awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). kind/enhancement Improvements or new features and removed needs-triage Needs attention from the triage team labels Sep 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
awaiting-upstream The issue cannot be resolved without action in another repository (may be owned by Pulumi). kind/enhancement Improvements or new features kind/question Questions about existing features
Projects
None yet
Development

No branches or pull requests

4 participants