svc: Assume access key creation permission to be available by default

[vadmeste]

Adding this policy will make the user not able to create a service account anymore:

    {
      "Effect": "Deny",
      "Action": [
              "admin:CreateServiceAccount"
      ],
      "Condition": {
              "NumericGreaterThanIfExists": {"svc:DurationSeconds": "1500"}
      }
    },

The reason is that policy.IsAllowedActions() is called with conditions from the user login.

Assume svc account creation to be possible for now until we come up with a better fix

[prakashsvmx]

@vadmeste ,

The Console UI already allows "Access Key " creation, by assuming this permission. but looks like a policy should be associated with the user to make it work.

e.g: a new user without any policy association results in Access denied when we trt to save the Service Account credentials from UI.
but if the user has readOnly policy. it works fine. ( though the policy does not explictly allow the action)

[vadmeste]

@prakashsvmx the current implementation does not work all the time. The reason is that we evaluate the default actions during the user's login, however this is not correct. A policy is evaluated during the API request itself. The request that is sent to the server contains sometimes some information (http headers or path or other) that will be transformed to conditions before the policy evaluation, and the policy decision will depend on the passed conditions from the request itself. So we cannot assume anything during the user's login.

But if we want to have a granular approach to this, I think we should move this API, policy.IsAllowedActions(), to Console code, it will be easier for us to tweak it when needed.

[harshavardhana]

@prakashsvmx the current implementation does not work all the time. The reason is that we evaluate the default actions during the user's login, however this is not correct. A policy is evaluated during the API request itself. The request that is sent to the server contains sometimes some information (http headers or path or other) that will be transformed to conditions before the policy evaluation, and the policy decision will depend on the passed conditions from the request itself. So we cannot assume anything during the user's login.

But if we want to have a granular approach to this, I think we should move this API, policy.IsAllowedActions(), to Console code, it will be easier for us to tweak it when needed.

@vadmeste we should only add this if there are "conditions" in the policy as part of the admin actions.

we should not out-rightly add permissions for allow locally without consulting the server policy.