ABacchi035478 (Community Member) asked a question.
How do you manage team API accounts?
I'm looking at creating an api account for any team who requests one to use for their pipeline. (there could potentially be 100s of teams) My thought is that each team will need to be the custodian of their own account credentials. (user name and password for login to retrieve API secret). The API secret expires one year after being issued- Do you as an adminstrator have a way to help teams deal with that? Please share your best practices you have come across with dealing with accounts.
.png){kind=logo}
It is definitely a good practice to create an api account for teams, utilizing a naming convention for account name like "api", or "service" to distinguish people from service accounts. For email, I prefer to use a group email account associated with the team, but that is not always possible. Remember, there are limitations w/email as username, but if you are using SAML for users, then there shouldn't be any problems. The service account would be an account in Veracode, and not available for SAML assertions.
With the Service account set up, I turn it back over the team for password and api secret creation. I personally don't like that api keys expire in a year, because it potentially could be the cause of an incomplete deployment (or wherever you have api scans integrated). Veracode sends a reminder things are about to expire to the email (why a group email is better than an individual).
While it is not possible to set the expiration date beyond 1 year, it is possible to submit a support ticket to have it extended up to 10 years. A feature like this should be made available w/in the Veracode platform, instead of submitting a support ticket, but extending the expiry is possible to do.
Excellent advice I really appreciate that! What is your opinion on having the security team who owns VC at the company own just one master API account which they put the creds into a shared Jenkins plugin for example and instruct teams to leverage that - pointing to their team and applications for their jobs?
It depends on the size of your company/enterprise. Also, whether you use single Jenkins instance or not for all your teams, and whether you want the sec team to own the service account.
In a large enterprise with many teams, build servers and application profiles, I would delegate this responsibility to the devOps engineers as part of their automation duties. They own the VC service account. DevOps teams don't like dependencies or having to wait on things. You don't want them to complain that Security is slowing them down!
In smaller or more centralized companies, it could make sense for the Sec team to own the service account, in that case you could get away with one (or few) service accounts, and manage password/key rotation yourself. If requirements change in the future, you could create additional service accounts and hand those out, if you wanted.