Creating ApiKeys in Connect which are owned by "service accounts"...

[slodge]

We're increasingly automating access to our Posit/RStudio Connect

This includes:

• continuous integration/build/deployment which deploys apps, reports and apis to Connect
• services which call plumber APIs to read data and charts

We have so far been connecting these automated clients using ApiKeys which are setup in normal user accounts (which are all connected to our domain using SAML to Azure Active Directory)

This works... but it means that for example published apps are connected to my user, and published APIs are accessed but my user... this leads to some inaccurate permission provisioning, and it will definitely become a problem if ever my account gets locked (e.g. if/when I leave).

To work around this, I've been looking at adding some kind of "service accounts" (e.g. called "Ms Build Pipeline" or "Mister Report Generator") to Connect - so that I can then create API Keys within their accounts - and can use those API Keys for accessing Connect.

My questions about this approach:

1. Is this the recommended sort of approach?
2. Is there any way to avoid these service accounts using up genuine slots on our license?
3. Is there any way to add these service accounts (and get API keys for them) just within Connect (e.g. using the usermanager CLI tool) without adding them to our domain and to our Azure AD based SAML auth system? (I'm not sure if this is possible - can Connect operate "local RStudio" accounts in addition to those that are specified from SAML?)

Sorry if this is a bit confused/confusing... still trying to work out myself exactly what we want...

[Lachlan_Simpson]

Hi @slodge,

Thanks for your questions.

@slodge

• Is this the recommended sort of approach?

At the end of the day, each administrator and org needs to make that judgement themselves, given their internal needs, resources, and processes.

Connect comes with comprehensive migration documentation and User Management commands that make transferral of applications between users relatively simple for cases like the one you have described. Obviously these processes can take anywhere between 5 minutes and half a day, depending on what you are doing, so you will need to make a judgement on how mission-critical the apps in question are.

@slodge

• Is there any way to avoid these service accounts using up genuine slots on our license?

Currently there is not - each account is treated equally.

@slodge

• Is there any way to add these service accounts (and get API keys for them) just within Connect (e.g. using the usermanager CLI tool) without adding them to our domain and to our Azure AD based SAML auth system? (I'm not sure if this is possible - can Connect operate "local RStudio" accounts in addition to those that are specified from SAML?)

There isn't any way to do this as you described.

Posit Connect only supports one active authentication provider at a time. Migration from one to another is a non-trivial effort and may require both user and content conversion. It is sometimes easier (depending on what the system has been used for) to create a new Posit Connect installation than it might be to migrate one.

https://docs.posit.co/connect/admin/authentication/

The one option you have here is the rstudio-connect user, the Connect system account. This can be changed to any account name you choose, but there can only be one of that user, so it doesn't allow for your desired per-process service accounts.

Another option would be if your SAML provider can integrate with sssd, then you can use PAM authentication. But that introduces further complexities.

I hope this helps.

[kellobri]

Hi @slodge, This falls pretty squarely in the realm of feature request territory. We don't have great solutions for this in Connect today, as Lachlan outlined and as you've discovered for yourself. I would love to get your feedback on some of the concepts we're considering though. I'll reach out via your CS rep to set some time up for a conversation.

[slodge]

Thanks both @Lachlan_Simpson and @kellobri - happy to talk whenever (although if it comes down to AD, domains, auth, SAML, Kerberos, etc then I might not be the best person to answer any of your questions!)

On this particular setup, our domain admins have sorted out an appropriately permissioned service account user, and I think we've settled internally on using that single user for both our builds and for our pin and plumber permissioning.

For shinyapp-or-report-to-pin and shinyapp-or-report-to-plumber configuration I can definitely imagine Connect could do some very useful passwordless magic for us in the future... but we don't have any immediate pressing need for this right now (for now, we can definitely make ApiKeys work).

Really, we're just getting started in this pin and plumber area - we've been mostly Rmd and Shiny users up to now - sorry, if that means we ask a lot of questions

Thanks again for the answers here