Required Domain Accounts - why?

I'm not sure if there's an operational reason, but I know there's a security concern.

Basically, if someone could compromise the account for the reporting service, you wouldn't want them to immediately have access to the source control repository - the service account necessarily has a fairly high level of access. It's "separation of privilege" and part of our defense in depth strategy.

So, operational/technical issues aside, there are good reasons for defining specific privileges for specific identities rather than using one catch-all service account.

Hopefully someone who knows more about setup and the reporting services can speak to whether there's a more fundamental "need" to use separate identities.

Here's a scenario present in pretty much every threat model:

"Attacker finds and exploits buffer overrun, runs code as process owner".

So, the question is always, what credentials did the attacker just gain? What privileges does that account have elsewhere?

If you run a process as system, the answer is very short and simple: GAME OVER, Man! The attacker can do literally anything he wants to the system. So, you generally don't want any non-OS core services running as System.

If an attacker finds a vulnerability in our Reporting component, and is able to exploit it to gain access to the account, he's still only able to do whatever that account can do. Therefore, limit what that account can do.

In the domain context, with properly configured accounts, that means he doesn't even gain login privs to any machine on the network. In theory, he'll only gain the exact set of permissions Reporting needs to function properly. In practice, we come as close to that as we can, and that may still imply privileges that are precious, but it WON'T be "anything and everything on this box" (if we used system) or "pretty much anything across Team Foundation" (if we used a common service account).

Using a single server does reduce the attack surface somewhat, as you said. But there are still attack vectors worth considering and mitigating where we can do so -- in this case, through careful configuration and administration.

If you're not worried about that kind of threat vector, then you can choose to disregard that particular guidance - people install SQL Server as System all the time, I'm sure. But, there's also the operational/technical aspect, that I can't speak to. Make sure you get an answer on that front if the security aspect doesn't worry you.

What Chris said was exactly right and the principle of "least privilege" certain plays a role in these kinds of decisions. However there's another reason. We imagine that many people will write reports. We want to limit the permissions of the account that reports run as so that a report can't change data in the database. Imagine someone wrote a report that had a bug in it that deleted rows from a critical operational table. This would be a very bad thing. It could be a malicious report writer or an accident. Either way we want to make sure that people writing reports can only do things reports should be able to do.