acs-engine should check that provided service principal (if any) has enough rights in the target subscription to create Azure resources

[ghost]

Is this a request for help?:
NO

---

Is this an ISSUE or FEATURE REQUEST? (choose one):
FEATURE REQUEST

---

What version of acs-engine?:
any

---

Orchestrator and version (e.g. Kubernetes, DC/OS, Swarm)
Kubernetes, but I assume it also applies to DC/OS and Swarm

What happened:
While acs-engine is able to deploy Azure resources in the target subscription, it never checks/warns that the service principal provided (if any) in the api-model file has the right to create resources in that subscription, like route tables, load-balancers, volumes, etc.
This can lead to non-working clusters like in #2100 (shame on me) if the service principal does not have proper rights in the target subscription.

Source of the confusion is that acs-engine does not rely on service principal to create a Kubernetes cluster and since ARM template is spotlessly processed, you have the feeling that you don't have any right issue, but the cluster won't be able to add any Azure resource and will fail to work properly.

What you expected to happen:
In case a service principal is provided in the api-model file, acs-engine should check that it has the right to spawn resources in the target subscription.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know:

[serbrech]

I had the same experience, the feedback loop of deploying a cluster is slow, and figuring out what went wrong in that case is not straight forward.

[serbrech]

Awesome!

[ghost]

Thanks!