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.
callmewilkoMember Since 21 Dec 2011
Offline Last Active Aug 07 2019 04:10 PM
- Group Members
- Active Posts 12
- Profile Views 1937
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
callmewilko hasn't added any friends yet.