Jump to content


callmewilko's Content

There have been 2 items by callmewilko (Search limited from 16-October 18)


By content type

See this member's

Sort by                Order  

#25212 How to give applications access to Perforce?

Posted by callmewilko on 07 August 2019 - 04:10 PM in General

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



#25210 How to give applications access to Perforce?

Posted by callmewilko on 07 August 2019 - 11:17 AM in General

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.