I haven't been able to find the answer [1,2] as to what "server rights" do service accounts need to have. I'm talking about IIS APPPOOL and K2 SERVICE ACCOUNT and the Admin, Impersonate and Export server rights.
What's the best practice in relation to service accounts rights within the K2 environment? do they need to have any server rights at all? If they do need server rights what scenarios are applicable?
 Server Rights Required by K2 blackpearl Accounts https://help.k2.com/kb000199
Good day EduardoLopez
Please see the following:
IIS Permissions for App Pool Accounts: https://help.k2.com/onlinehelp/k2five/icg/5.3/default.htm#Prepare/SetPermSA-IIS.htm,
All deployment actions use the K2 Server Service account: https://help.k2.com/onlinehelp/k2five/userguide/5.3/default.htm#K2-Workflow-Designer/Permissions/Per...,
Create Service Accounts and assign permissions: https://help.k2.com/onlinehelp/K2Five/ICG/5.3/default.htm#Prepare/Create-Service-accounts.htm, Permissions needed for common tasks: https://help.k2.com/onlinehelp/k2five/userguide/5.3/default.htm#Permissions/Permissions-Common-Tasks....
I also dont see it being mentioned anywhere, but looking at a freshly installed server:
* K2 Service Account has: Admin, Impersonate, Export
* App Pool Account: Admin, Impersonate
I'm sorry but this does not answer my original question. I doubled checked https://help.k2.com/onlinehelp/K2Five/ICG/5.3/default.htm#Plan/Accounts.htm, and the other links, and it does not say anything about K2 server rights.
In the STRIDE  model giving unnecessary permissions to accounts (or in this case service accounts) has a risk of Information disclosure or Elevation of privilege.
I want to know what would happen if I remove all K2 service rights to the service account and application pool accounts. I assume nothing will happen immediatly if I do it, however, I don't want to have any surprises going forward due to this configuration change; hence the request for best practices.
 The STRIDE Treat Model https://docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20)?redirectedfrom=...
It just doesn't feel right to assign Admin rights to the service accounts; if the AppPool account is compromised I'll have a very bad day.
Interesting question, here are some thoughts. I would think they need some server rights, but based on what functionallity to use. For example if you are using app wizards the service account needs export rights to be able to generate the app.
And I think impersonate is needed to impersonate with kerberos.
But right now i can't figure out when the admin permission could be needed. One thing could be that if the service account is not admin it would loose all the permissions to the category tree, including the system smartobjects. I have also stumbled upon that when calling the K2 api the user had to be admin to be allowed to do the call, this could potentially be a problem since i guess that the K2 service account is doing a lot of internal calls.