Feature: add resource anypoint_team_role for assigning independent roles

[drdamour]

the https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/console/method/%2314279/ service currently leveraged by anypoint_team_roles does not have to be used in an all or nothing style.

Anything you post to it is additive and idempotent. As such it can be used to implement an anypoint_team_role resource that looked like:

resource "anypoint_team_role" "grant_org_admin_to_it_admin_team" {
  org_id  = anypoint_team.it_admin.org_id
  team_id = anypoint_team.it_admin.id

  role_id = local.role_ids.bg_scoped.org_admin
  context_params = {
    org = roles.value.id
  }

}

on a refresh this would pull from the GET roles and match on the org,team, role id & environment id (can be missing) to make sure it's present, if not create.

deleting a specific granted role is supported via the delete operation too https://anypoint.mulesoft.com/exchange/portals/anypoint-platform/f1e97bc6-315a-4490-82a7-23abe036327a.anypoint-platform/access-management-api/minor/1.0/console/method/%2314291/ so that is solved as well, if those pairs are

a note would have to be made to choose between anypoint_team_roles which ensures there are no additional roles and anypoint_team_role for a given team's permissions as they would conflict with each other

this would allow for scenarios to grant specific permissions to teams consistently from modules that create bg's and environment's in an additive fashion. eg:

module "app_x" {
  source                 = "../modules/app/"
  name                   = "X"
  business_group_id      = anypoint_bg.apps_parent.id
  root_business_group_id = data.anypoint_bg.root.id
  role_id_by_name_lookup = local.role_ids

  # here's what we can do now...the app module can add permissions for this apps' bg & environments to this team additively
  org_admin_team_id = anypoint_team.it_admin.org_id

  deployable_environments = [
    "test",
    "prod",
  ]

}

[soufi]

Hi @drdamour, Thank you for pointing this out. Would you be willing to contribute here to document this new resource ? This would allow me to implement it in the provider affectively. If you need any help/guidance, you can reach me out on Discord

[drdamour]

@soufi my corp blocks discord so gh thread is better.

This is the same backing service that anypoint_team_roles works with today so it would just be copy paste of that..is that what u want?

the difference is in how the provider builds the payloads.

[soufi]

Hi @drdamour, Basically the pre-requisite to implementing this new feature is to write the OAS spec here. Please follow the guidelines in the README file. you can look into the other specs for inspiration.

the OAS spec is the basis for the provider client to anypoint. it's the abstraction layer that allows us to call the anypoint resource and execute the requests. In other words, we generate the anypoint client from the specs.

The result is here.

I encourage you to read this repo's README file, it has the basic concepts of our framework.

Thank you

[drdamour]

@soufi i understand, but this isnt a new resource needed by the client…its the same as the already existing one just used differently. So you want the same resource twice?

[soufi]

@drdamour in order to deliver the above we need to add a new endpoint to the already existing resource.

[drdamour]

@soufi i'm still not following...all the services are already there: GET is here https://github.com/mulesoft-anypoint/anypoint-automation-client-generator/blob/94d0f8794d3f865bbb81529bd19551c33014f343/spec/team_roles.yaml#L20 POST (for adding one role assignment is here): https://github.com/mulesoft-anypoint/anypoint-automation-client-generator/blob/94d0f8794d3f865bbb81529bd19551c33014f343/spec/team_roles.yaml#L68C3-L68C3 DELETE (for removing one role assignment here): https://github.com/mulesoft-anypoint/anypoint-automation-client-generator/blob/94d0f8794d3f865bbb81529bd19551c33014f343/spec/team_roles.yaml#L93

i re-emphisize the change has nothing to do with the spec, it's the way you use the spec. but i very well may be missing something? i just don't understand why you want me to duplicate what's already there.

[soufi]

@drdamour, my apologies I misunderstood. I thought a new API endpoint was created to manage roles from an individual level.

It is possible to create a single role for a team and manage it individually, but that would require a bit more development to read the specific role from the list of roles.

Are you interested in developing this particular resource ?

[drdamour]

@soufi interested, yes..capable…no

Dunno the go ecosystem but i suspect it has the concept of a filter monad and thus matching the role out of the get response shouldnt be too hard. A principal identity can only be assigned a role once for a bg/env(optional) so its a simple equality filter on that 3 part tuple

[soufi]

@drdamour, just start, It's pretty easy to, the code is done in the simplest way possible :)

I'll look at it as soon as I finish what I'm doing right now. I'm working on all the resources around api management, secret-management and flex gateway

[georgy-varghese]

Hi @soufi, Thanks for the provider. Is there a timeline when you plan to release the new resources for api management, secret management and flex gateway.

[soufi]

Hi @georgy-varghese, You can join us in discord for more up to date info. I would like to release this on February. You can already use some of those in the dev branch (I push stuff there regularly).