I’ve run CI for games pushing to steam. The best way is to ensure a lock on steam operations to only allow one in parallel any time across your CI. Download the steam works sdk for your CI runner platform, bootstrap it locally, and log in manually once. 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.
> 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.
> Doesn't that effectively defeat the purpose of 2FA?
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.
> 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 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.
Yeah, I'm not arguing for multiple approvals to deploy a suite of things, but one approval which is authenticated for doing it all, nor am I arguing to somehow add more authentication on top of what you already have, you'd obviously aim for one integrated process.
But regardless, I hear your point and agree with lots of other things you wrote.
And that integrated process in a world where you ahve multiple providers (Steam, PSN, Xbox) is likely your CI provider. As long as the token generation is correct, and you treat the vdf files like any other build secrets, it's no worse than GHA being able to deploy to AWS and having 2FA on your AWS console access.
I'd protect my GitHub account with 2FA and configure GitHub Actions to trigger on creating a release in GitHub. That way my release process is fully automated but still protected by 2FA, in this case GitHub's 2FA implementation.
