inlets/inletsctl

Following `inletsctl create` docs for Azure fails with authorization errors.

eltariel opened this issue · 5 comments

eltariel commented

The reference docs for AWS and GCE both contain detailed instructions for setting up the authorization needed to run inletsctl create. The corresponding docs for Azure are incomplete and following them doesn't work without an extra step.

Expected Behaviour

  1. Install inletsctl
  2. Follow the steps listed here: https://docs.inlets.dev/reference/inletsctl/#example-usage-with-azure
  3. Inlets is deployed successfully

Current Behaviour

  • az ad sp create-for-rbac --sdk-auth > ~/Downloads/client_credentials.json prints the following but succeeds anyway:
WARNING: Option '--sdk-auth' has been deprecated and will be removed in a future release.
  • The inletsctl create command shown in the docs (with my subscription id instead of the one in the docs) fails with the following output:
Using provider: azure
Requesting host: elegant-sammet6 in eastus, from azure
2022/01/30 15:40:01 Provisioning host with Azure
2022/01/30 15:40:01 Creating resource group inlets-elegant-sammet6
resources.GroupsClient#CreateOrUpdate: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '<service-principal-object-id>' with object id '<service-principal-object-id>' does not have authorization to perform action 'Microsoft.Resources/subscriptions/resourcegroups/write' over scope '/subscriptions/<my subscription id>/resourcegroups/
inlets-elegant-sammet6' or the scope is invalid. If access was recently granted, please refresh your credentials."

Possible Solution

The service principal needs to be granted the appropriate authorization to be able to create the resources needed. This is clearly overkill, but assigning the service principle the 'Owner' role at the subscription level works:

az ad sp create-for-rbac -n inletsctl --sdk-auth > az-sp.json
CLIENT_ID=$(jq -r '.clientId' az-sp.json)
SUBSCRIPTION_ID=$(jq -r '.subscriptionId' az-sp.json)
az role assignment create --assignee $CLIENT_ID --role "Owner" --subscription $SUBSCRIPTION_ID
inletsctl create --provider=azure --subscription-id=$SUBSCRIPTION_ID --region=australiaeast --access-token-file=az-sp.json

It should be possible to narrow down the actual permissions required to run the deployment.

Your Environment

  • inlets PRO version: 0.9.3 - 8e96997499ae53c6fb2ae9f9e13fa9b48dcb6514
  • inletsctl version: 0.8.14 - 4034ead
  • Cloud provider and region being used: Azure, eastus and australiaeast
  • Operating System and version (e.g. Linux, Windows, MacOS): WSL2
alexellis commented

Hi @eltariel thanks for mentioning this.

We don't see to have a record of you as a customer. Sorry if I am not connecting the dots.

It should be possible to narrow down the actual permissions required to run the deployment.

This was working when it was contributed by the community, but I don't personally use Azure (often) so haven't tested it recently. We would be open to a contribution if you can come up with an alternative for the documentation.

Alex

eltariel commented

Hi @eltariel thanks for mentioning this.

We don't see to have a record of you as a customer. Sorry if I am not connecting the dots.

No worries, I'm not actually a customer yet. I've been evaluating options for my little pi cluster (your guides have been super helpful with getting that going!) and inlets looks like a winner.

It should be possible to narrow down the actual permissions required to run the deployment.

This was working when it was contributed by the community, but I don't personally use Azure (often) so haven't tested it recently. We would be open to a contribution if you can come up with an alternative for the documentation.

Alex

I'll have a look when I get a chance and see if I can find a more precise set of permissions. I'm still fairly new to azure myself, I just happened to have some free capacity available.

alexellis commented

The feedback is appreciated, however I should make it clear that you do need a valid license or Gumroad subscription to deploy, launch or use inlets-pro in any way.

inletsctl is really a utility method for creating VMs and preinstalling the server component. It's optional, and shouldn't affect your Pi cluster. The same goes for using it in-cluster, where Helm may be preferable over the operator for a tunnel for ingress: https://inlets.dev/blog/2021/12/06/expose-traefik.html

Alex

  • 👍1
eltariel commented

The feedback is appreciated, however I should make it clear that you do need a valid license or Gumroad subscription to deploy, launch or use inlets-pro in any way.

inletsctl is really a utility method for creating VMs and preinstalling the server component. It's optional, and shouldn't affect your Pi cluster. The same goes for using it in-cluster, where Helm may be preferable over the operator for a tunnel for ingress: https://inlets.dev/blog/2021/12/06/expose-traefik.html

Alex

Thanks for the comments. My understanding is that both inletsctl and inlets-operator use the same method for deploying the vm, and I was mostly checking that would work before I tried to figure out how to use inlets-operator. Exposing services on my cluster isn't the only use case I have for inlets 😄

Just want to clarify that I haven't attempted to actually use inlets-pro yet, just verifying that the vm creation was as straightforward as it appeared. I had intended to grab a licence before installing the local end of the tunnel, and the vm was only live for long enough to validate that it created correctly. Apologies for misinterpreting the licence, I was under the impression that I would be fine to test this functionality as the licence appears to be tied to the client rather than the server. (Please note this isn't meant to be sarcastic, I can't work out any other way to phrase it though)

alexellis commented

Personal licenses are priced at a trivial amount of money per month, so that you can trial them on a month by month basis. If you like inlets, you can upgrade to annual pricing for an additional discount on the costs.

The license is enforced on the client so as not to make server tunnel maintenance a thing, but the whole application is subject to the EULA and requires a valid license.

The product actually works as advertised and has dozens of active commercial and personal users, so I would encourage you to purchase and commit to it. Or find a free alternative if that suits your needs better. There will be trade-offs whatever you do. I talk a bit more about that here -> https://inlets.dev/blog/2021/07/27/monthly-subscription.html

And here -> https://inlets.dev/blog/2021/12/31/inlets-2021-highlights.html

If you want ingress for your K8s cluster, I prefer this method -> https://inlets.dev/blog/2021/07/08/short-lived-clusters.html