The account under which the SQL Server service is running on a cluster must be a domain (Windows) account and that account needs SysAdmin rights within SQL Server.

The account under which the Cluster service is running must also be a domain account and must be able to connect to the server. It does not need any specific rights except the public role against the master database (or maybe whatever it's default database is, although I've never tried changing that).

These accounts must be domain accounts. You can tie them down fairly well by using a Windows policy to prevent them being able to log on locally.

Once you've got these accounts set up you can drop all other domain/local Windows accounts if you really want to: the first one we drop is BUILTIN/Administrators.

Note that using Windows authentication is the recommended model in every best practice article I can remember reading, and that is especially so in pre-SQL2k8 versions where the password management of SQL Server accounts is almost impossible to force into regulatory-compliant policies except through external controls.

As the other responders have said, you should be absolutely certain what it is that you're trying to achieve before making any changes, and test them elsewhere before implementing them on your production system.