|
|
|
|
|
by diggan
457 days ago
|
|
> Then push the entire sdk directory into S3, and in CI you then pull it, login without a password, and push the entire thing back to S3 again. Doesn't that effectively defeat the purpose of 2FA? Personally, I feel like I'd automate it in a way that everything up until that point is automated, but the actual "release" (upload really) to Steam would be in a different step that asks for the 2FA every single time, on purpose, so I actually get the benefits of a 2FA together with automating most of the pipeline while still having control of the final release. |
|
Yes and No. You need to 2FA in the first place to get the credentials in place. After that it's just basic secrets management - your steam credentials are no more or less secure than your playfab developer secret that you use to upload servers, or the credentials that you use on your AWS machine to do the deploy.
There's no way to generate a service token for steam that says "this is allowed to deploy builds only", like a gha token, or an AWS credential. Both of those require you to 2FA to generate the token in the first place. Ultimately, if steam really cared about security they would allow for something like this, like every other modern provider does. But they haven't exactly kept up with "modern" best practices.
> Personally, I feel like I'd automate it in a way that everything up until that point is automated, but the actual "release" (upload really) to Steam would be in a different step that asks for the 2FA every single time, on purpose, so I actually get the benefits of a 2FA together with automating most of the pipeline while still having control of the final release.
You can't upload builds above a certain size manually to steam, you need to use steamcmd. Steam isn't just for releasing public builds, we use it for playtesting for example. So our CI uploads versions of our game to private betas on steam for our team to be able to jump into, like a staging environment. Requiring a manual step for that in another tool, with another set of credentials and scopes to manage is a bigger risk (IMO) than managing an extra secret. If you do these steps as manual steps but make the "release" step a manual step, then you've introduced a massive untested failure point in your deployment pipeline that happens at the latest possible moment. If you have servers to manage, or clients on another storefront (Epic, GoG, PSN/Xbox) you need to ensure versions are coordinated; and now you're potentially asking someone to log into 5 dashboards to set manually upload versions and set builds.
There's no reason games should be exempt from CICD best practices, IMO.