Non-admin access to volumes does not work

[andrewsav-bt]

Kind of issue

Bug

Observed behavior

With user (non-admin) credentials the following check is performed:

	if "user" == claims.Issuer && r.URL.Path != "/volumes" {
		http.Error(w, "Administrator access required", http.StatusUnauthorized)
		return
	}

This prevents the following API from working when "user" credentials are used:

• Volume Information
  Method: GET
  Endpoint:/volumes/{id}

• Expand a Volume
  Method: POST
  Endpoint:/volumes/{id}/expand

• Delete Volume
  Method: DELETE
  Endpoint:/volumes/{id}

In particular it is not possible to get Volume Information or delete a Volume with user credentials. It appears that user credentials were designed with the idea, that kubernetes provisioner can run under user credentials. However a provisioner needs to be able to get information about existing volumes and delete volumes.

In addtion heketi-cli commands such as volume list issues GET on /volumes/{id} which causes message "Administrator access required" when trying to list volumes under user credentials.

Similarly, in kubernets, when creating a persistent volume claim we get "Failed to provision volume with StorageClass glusterfs-storage: failed to create volume: failed to create volume: Administrator access required"

Expected/desired behavior

According to the documentation:

• admin: Has access to all APIs
• user: Has access to only Volume APIs

User is supposed to have access to Volume API. This includes Volume Information and Delete Volume API.

Details on how to reproduce (minimal and precise)

Make sure that authentication is turned on for the server.
Run:

heketi-cli -s http://server:port --user user --secret secret volume list

Observe:

Error: Administrator access required

Information about the environment:

• Heketi version used: Heketi v7.0.0-129-g4c7d19c
• Operating system used: docker container
• Heketi compiled from sources, as a package (rpm/deb), or container: container
• If container, which container image: heketi/heketi:dev
• Using kubernetes, openshift, or direct install: kubernetes
• If kubernetes/openshift, is gluster running inside kubernetes/openshift or outside: inside
• If kubernetes/openshift, how was it deployed (gk-deploy, openshift-ansible, other, custom): gk-deploy

[phlogistonjohn]

Great issue, thank you for filing it. This is quite annoying and has lead to confusion in a number of situations.

[pashok2398]

+1
Same problem using heketi/heketi:dev docker image.
Thanks

[hmeerlo]

So, any news on this? I'm hitting the same problem and have no clue how to fix this.

[ook]

@hmeerlo you can workaround this issue by using the admin credentials instead of user's one, but that's… creepy.

[phlogistonjohn]

The bug is here: https://github.com/heketi/heketi/blob/master/apps/glusterfs/app_middleware.go#L39
in that the path is checked exactly and not as beginning of a url "subtree". Volunteers who want to take this up would be very welcome.

[phlogistonjohn]

As heketi is now in maintenance mode, and only accepting major bug and security related fixes, we do not expect to implement this change.