Question: Hability to configure account to login via SSO and add users to it

[rogerioefonseca]

Hello there, me again. I was not able to find resources to configure the account to log in via SSO with azure and to add users to it. We were able to do that via GUI, but it would be nice to have that as terraform resources as well. Is that in your roadmap plan to develop and release, and if yes :), what is the ETA?

Best, and thanks in advance

[ConfluentSpencer]

Hey @rogerioefonseca, We are looking at enabling this but don't currently have a timeline for when we might be able to do this work. Can you give more background on how much easier your TF workflow might be if we enabled this? How much pain is there for you without this capability?

[rogerioefonseca]

Hello @ConfluentSpencer , thanks for the reply. So the point is that we a treating Confluent Cloud like other Cloud service providers, which means that we are trying to automate as much as possible and reduce manual tasks and documentation to do so. The second one is that we are moving our current on-premise solution to Confluent Cloud and we would like to grant the Development team(300 people), that is onboarding and offboarding constantly, access to the GUI. Honestly, now the effort is not painful, but then we need to generate more documentation to do so and we are not able to automate Onboarding and Offboarding in regards to Confluent Cloud. I know that we could try to use confluent CLI + terraform to do so, but that is not something that we are promoting internally. In the future, we would be happy if the IAM is "terraformed".

[nick-osborn]

Adding a +1 for this for 2 distinct use cases

1)To immediately tie users that have been added from our SSO provider(Okta) to the Confluent Cloud side. At the moment, they are added through automation to the SSO acct and then someone with admin access has to add the email name on either CLI or CC UI end. From there we can import as a data source to manage RBAC for users.

2)To tie api_keys for ksqldb to specific users. The main idea is that in dev(and or sandbox) we allow a select group of users to have semi-unfettered access for testing with the understanding that the api_keys that they own are used for auditing.

Im open to any reasoning security-wise for why it wouldnt make sense as I'm no expert from Confluent Kafka perspective. Also, let me know if any screen grabs or sample tf code is needed for how we're currently utilizing this/planning to use

[rogerioefonseca]

Hey there @nick-osborn , I would appreciate it if you could share a sample of the CLI code that you are using to add users to Confluent Kafka. That could save me some time. Thanks in advance

[nick-osborn]

For adding users we either add the email in Confluent Cloud or confluent cli with this command - confluent iam user invitation create user@company.com. From there, as long as the user isnt identified as a local user it will automatically tie to the identity provider that was set up. I dont have the info for the idp setup as it was before my time at the company. Once the user is added we can pull with user data source and add rbac roles to it

data "confluent_user" "email" { email = var.sso_email_id }

resource "confluent_role_binding" "sso-access-rbac-env" { principal = "User:${data.confluent_user.email.id}" role_name = var.role_name crn_pattern = var.rbac_crn }

I pass in a list with for_each calling that module to set access for various groups at whatever level they need to be (admin at cluster level, operator at org level, etc)

Not sure if thats what you were looking for but hopefully it helped.

[vweckerle]

+1 This feature would also be extremely helpful for our Confluent Cloud use cases. The most crucial TF resource we're missing would be something like confluent_user which would allow us to create a new SSO user/invite by providing just an email address. Right now user management for Confluent Cloud is very tedious for us as we always have a manual step in-between somewhere to create or remove a user in Confluent Cloud.

[rogerioefonseca]

data "confluent_user" "email" { email = var.sso_email_id }

resource "confluent_role_binding" "sso-access-rbac-env" { principal = "User:${data.confluent_user.email.id}" role_name = var.role_name crn_pattern = var.rbac_crn }

Thanks @nick-osborn

[nick-osborn]

Wanted to check here really quick. I have noticed some new additions to the recent terraform provider changes for identity providers and also that there is invitations api in the API(https://docs.confluent.io/cloud/current/api.html#tag/Invitations-(iamv2)/Quotas-and-Limits ) that feeds Confluent TF. @linouk23 Is this feature request represented in those or coming up pretty quick? Or is there some underlying dependencies before thats presented as a TF resource?

[linouk23]

@nick-osborn that's a great question!

Do you think confluent_identity_provider and confluent_identity_pool resources added in 1.2.0 version of TF Provider resolve this feature request?

[nick-osborn]

@nick-osborn that's a great question!

Do you think confluent_identity_provider and confluent_identity_pool resources added in 1.2.0 version of TF Provider resolve this feature request? @linouk23

I feel like those get the backend setup for the SSO provider but I kinda expected something like a confluent_user resource that would follow from that. We have the data source for it but not a resource. Id expect something like this I think:

Stealing a bit from AWS Cognito provider :)

resource "confluent_identity_provider" "okta" { display_name = "My OIDC Provider: Okta" description = "My description" issuer = "https://mycompany.okta.com/oauth2/default" jwks_uri = "https://mycompany.okta.com/oauth2/default/v1/keys" }

resource "confluent_identity_pool" "example" { identity_provider { id = confluent_identity_provider.okta.id } display_name = "My Identity Pool" description = "Prod Access to Kafka clusters to Release Engineering" identity_claim = "claims.sub" filter = "claims.aud==\"confluent\" && claims.group!=\"invalid_group\"" }

resource "confluent_user" "example" { user_pool_id = confluent_identity_pool.example.id username = "example" email = "user@company.com" } ^ might also be sso_confluent_user or have an sso=true flag if there's a possibility of conflict with non-sso users

[nick-osborn]

Hey @linouk23, Checking back on this. Did what I mentioned make sense or am I missing something there? Im curious if there's been any traction since it looks like a lot of the api's that would support this appear to be available.

[linouk23]

Hi @nick-osborn, unfortunately I'm not super well versed about it overall, I think https://docs.confluent.io/cloud/current/api.html#tag/Invitations-(iamv2)/Quotas-and-Limits is our roadmap. Would it be a step in the right direction here?

resource "confluent_user" "example" {
user_pool_id = confluent_identity_pool.example.id
username = "example"
email = "[user@company.com](mailto:user@company.com)"
}

There might be some plans to support a resource confluent_user but I'm not sure whether it'll have user_pool_id attribute 🤔 I think overall our approach has been to make TF stay away of managing users directly even though we can see some TF providers do manage them: Azure api_management_group_user api_management_notification_recipient_user api_management_user AWS: appstream_user aws_connect_user aws_cognito_user aws_elasticache_user aws_iam_user :fb-wow: aws_memorydb_user GCP: google_sql_user

I'm not sure I answered your question but hopefully that was somewhat helpful.

[nick-osborn]

Hey @linouk23, Ive looked at this a few times while my mind was on other things and for some reason it wasnt clicking. I think that should be fine. Admittedly I havent looked very closely at the SSO resources yet although really need to very soon. Ill see if I can get some time to look into it a bit more deeply but I think it should work. More than anything, we just need a way to add users without having to run a cli command for it and the more things we can do directly from TF the better. If thats what you have proposed then I think it should work.

[linouk23]

More than anything, we just need a way to add users without having to run a cli command for it and the more things we can do directly from TF the better. If thats what you have proposed then I think it should work.

Adding integration with Invitations API is on the roadmap too.

[krush-fwtv]

data "confluent_user" "email" { email = var.sso_email_id }

resource "confluent_role_binding" "sso-access-rbac-env" { principal = "User:${data.confluent_user.email.id}" role_name = var.role_name crn_pattern = var.rbac_crn }

Hi @nick-osborn and @linouk23 , I tried importing existing roles into confluent_role_binding, but it requires a role-binding ID for the import.

• I couldn't find that ID in the UI or in the CLI outputs
• It seems too cumbersome to figure it out from the API. It looks like for the prinicipal, one has to keep finding and passing the user-id and then for each user, we have to contruct CRN for every permission level to get role-binding ID. Looks like I need to write a script that will figure out this ID at all levels by users and then use it in Terraform imports. Is there a better way to do the imports? Would it be possible to display role-binding IDs in the Confluent UI, right next to the assigned role?

[linouk23]

@krush-fwtv thanks for reporting that! It is a known limitation that we're trying to fix but short term, as you mentioned, writing a script might be the easiest "fix".

[nick-osborn]

@linouk23 I see this just dropped - https://registry.terraform.io/providers/confluentinc/confluent/latest/docs/resources/confluent_invitation

Ive been a bit behind on updates here lately(you guys are moving fast but keep going :) ). Ill try and get a chance to add these into our modules to see if this solves this issue.

[linouk23]

@nick-osborn you're welcome!

Let me know if that helps to resolve the current issue, thanks!

[linouk23]

cc @rogerioefonseca @krush-fwtv @vweckerle

We've just released a new version of TF Provider for Confluent that includes new confluent_invitation resource and a corresponding data source in a Preview lifecycle stage.

Let me know if that helps with this issue!

[linouk23]

cc @nick-osborn @rogerioefonseca @krush-fwtv @vweckerle

We've got a quick question: will it be helpful if we rename confluent_invitation to confluent_user (that leverages both Invitations API and Users API) and allow you folks to manage users via TF instead of having a bunch of accepted confluent_invitation resources that might be tricky to delete (AFAIK a user gets 400 when they try to call Delete an Invitation when the invitation is already accepted)?

[nick-osborn]

Yes, that would be very much my preference. It would make it easier for those that dont fully understand the difference between adding a user and using invitation as well.

[froblesmartin]

cc @nick-osborn @rogerioefonseca @krush-fwtv @vweckerle

We've got a quick question: will it be helpful if we rename confluent_invitation to confluent_user (that leverages both Invitations API and Users API) and allow you folks to manage users via TF instead of having a bunch of accepted confluent_invitation resources that might be tricky to delete (AFAIK a user gets 400 when they try to call Delete an Invitation when the invitation is already accepted)?

HI @linouk23 ! Is there any update about the confluent_user resource. If the invitation does cause issues because it does not really manage users, we would rather wait for the specific user resource.

[linouk23]

@froblesmartin as it looks right now, we'd require a new backend API to release confluent_user which might not happen in the near future so you might want to use confluent_invitation resource instead.

[maxmanus96]

Looking for updates, thanks!