Jump to content

How to give applications access to Perforce?

  • Please log in to reply
2 replies to this topic

#1 callmewilko



  • Members
  • PipPip
  • 12 posts

Posted 07 August 2019 - 11:17 AM

Today our build systems, information radiators and integrations are given access to Perforce via a dedicated user whose password never expires that is locked to specific IP addresses with p4 protect. This has some problems:

- trying to move to building things in containers or other on-demand build infrastructure with unpredictable IPs can't work like this
- it's too slow to get a new machine added to the "protect" list (too slow for automation, that is)
- it's too easy for access to still exist on IPs that are no longer used for builds, representing a hole in the security (actually the least of my concerns)
- it's all managed centrally, so configuration of that user etc is all via a support team

Because of the first point above, for some modern build infrastructure we have to use real people's accounts which are not IP locked but whose passwords expire, and that is difficult to update that single password when there are builds going on. There's always a moment when something has the wrong password.

Ideally I'd like something like access keys where an application can have more than one active key:
- when rotating the keys you can expire the old one after finishing deployment of the new one
- nothing lives forever
- they are easily deployed by automated systems from a vault to unpredictable IPs

From looking around I _think_ the "correct" thing to do might be to create a user account per application (so an application can be revoked, and more to the point, owned) and then have a host independent ticket generated, presumably with a lifetime of the "ticket rotation" policy, say 3 months.

There's problems there for me:
- I don't know if a user account can have more than one live ticket at rotation time
- I think the business is charged by the number of users, so will doubtless not want to create multiple users just to manage application access
- Even if that worked, it is a long way from the convenience of (for example) GitHub Enterprise "access tokens" or AWS secrets and keys where a user with permission can generate keys for an application.

Are there better ways to manage access to perforce for on-demand systems?
Am I missing something in the Perforce world because I'm not an admin?

I'm particularly interested in how other people manage perforce access from ephemeral infrastructure in the context of enterprise style deployments.

#2 Sambwise


    Advanced Member

  • Members
  • PipPipPip
  • 1172 posts

Posted 07 August 2019 - 03:37 PM

Have you looked at the SSO functionality?  That might give you a little more flexibility than something involving the native password support:


You're correct in your suspicion that a user can't have more than one live ticket; each user has only a single server-side ticket, and the "hostless" ticket is just the raw form of that while the default host-bound ticket issued to clients is a hashed version of it.  When you "refresh" an open login session by running login again, it extends the lifetime of that same ticket (by a third of the timeout value or something like that), so you can't have different ticket lifetimes for the same user across multiple hosts.

Historically Perforce has issued "background user" licenses to support automation that's distinct from human users, but I'm not sure if that's still something that's offered.

#3 callmewilko



  • Members
  • PipPip
  • 12 posts

Posted 07 August 2019 - 04:10 PM

Thanks @Sambwise - the SSO is new to me so I'll read up on that.

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users