NoPermission error when generating Alicloud RAM credentials using STS Assume Role

[mikeadityas]

Describe the bug When trying to generate Alicloud RAM credentials using STS AssumeRole method, the API returns this error:

Error reading alicloud/creds/test: Error making API request.

URL: GET https://127.0.0.1:8200/v1/alicloud/creds/test
Code: 500. Errors:

* 1 error occurred:
    * SDK.ServerError
ErrorCode: NoPermission
Recommend: 
RequestId: xxxxxx
Message: You are not authorized to do this action. You should be authorized by RAM.

On Alicloud side, I've configured these things:

1. RAM user to be used by Vault user: vaulttest

2. Policies attached to the RAM user Custom policy config:

   {
   "Statement": [
       {
           "Action": [
               "ram:CreateAccessKey",
               "ram:DeleteAccessKey",
               "ram:CreatePolicy",
               "ram:DeletePolicy",
               "ram:AttachPolicyToUser",
               "ram:DetachPolicyFromUser",
               "ram:CreateUser",
               "ram:DeleteUser",
               "sts:AssumeRole"
           ],
           "Effect": "Allow",
           "Resource": "*"
       }
   ],
   "Version": "1"
   }

3. RAM roles to be assumed ARN: acs: ram::12345:role/ossfullaccess Trust Policy Config:

   {
   "Statement": [
       {
           "Action": "sts:AssumeRole",
           "Effect": "Allow",
           "Principal": {
               "RAM": [
                   "acs:ram::12345:user/vaulttest"
               ]
           }
       }
   ],
   "Version": "1"
   }

   It only has one system Policy attached (AliyunOSSFullAccess):

   {
   "Statement": [
       {
           "Action": "oss:*",
           "Effect": "Allow",
           "Resource": "*"
       }
   ],
   "Version": "1"
   }

Vault side configuration:

1. vault read -format=json alicloud/role/test

   
   {
   "request_id": "xxxxx",
   "lease_id": "",
   "lease_duration": 0,
   "renewable": false,
   "data": {
   "inline_policies": null,
   "max_ttl": 0,
   "remote_policies": null,
   "role_arn": "acs: ram::12345:role/ossfullaccess",
   "ttl": 3600
   },
   "warnings": null
   }

2. `vault read -format=json alicloud/config`
```json
{
  "request_id": "xxxxx",
  "lease_id": "",
  "lease_duration": 0,
  "renewable": false,
  "data": {
    "access_key": "VAULTTEST_ACCESS_KEY_ID"
  },
  "warnings": null
}

I've tried using the credentials of vaulttest user directly on aliyun-cli and it returned the dynamic credentials without problem.

To Reproduce Steps to reproduce the behavior:

1. Generate the necessary RAM user, Custom Policy to assume role, and RAM roles with proper trust actor

2. Run vault secrets enable alicloud

3. Run

   vault write alicloud/config \
   access_key=RAM_USER_ACCESS_KEY_ID \
   secret_key=RAM_USER_ACCESS_KEY_SECRET

   (change RAM_USER_ACCESS_KEY_ID and RAM_USER_ACCESS_KEY_SECRET with proper credentials generated earlier)

4. Run

   vault write alicloud/role/test \
   role_arn='acs:ram::UID:role/ROLE_NAME'

   (change UID and ROLE_NAME with proper values generated earlier)

5. Run vault read alicloud/creds/test

6. Error mentioned above will be returned here

Expected behavior It should return a set of dynamic Alicloud RAM credentials

Environment:

• Vault Server Version (retrieve with vault status): 1.0.2
• Vault CLI Version (retrieve with vault version): 1.0.2
• Server Operating System/Architecture: Ubuntu 18.04.1 LTS

Vault server configuration file(s):

storage "etcd" {
    address = "https://127.0.0.1:2379,https://127.0.0.1:22379,https://127.0.0.1:32379"
    etcd_api = "v3"
    ha_enabled = "true"
    path = "vault-data/"
    tls_ca_file = "/path/to/ca.pem"
    tls_cert_file = "/path/to/server.pem"
    tls_key_file = "/path/to/server-key.pem"
}

listener "tcp" {
    address = "127.0.0.1:8200"
    cluster_address  = "127.0.0.1:8201"
    tls_disable = "false"
    tls_cert_file = "/path/to/server-ca-bundle.pem"
    tls_key_file = "/path/to/server-key.pem"
}

disable_mlock = 1
api_addr = "https://127.0.0.1:8200"
cluster_addr = "https://127.0.0.1:8201"

storage "etcd" {
    address = "https://127.0.0.1:2379,https://127.0.0.1:22379,https://127.0.0.1:32379"
    etcd_api = "v3"
    ha_enabled = "true"
    path = "vault-data/"
    tls_ca_file = "/path/to/ca.pem"
    tls_cert_file = "/path/to/server.pem"
    tls_key_file = "/path/to/server-key.pem"
}

listener "tcp" {
    address = "127.0.0.1:28200"
    cluster_address  = "127.0.0.1:28201"
    tls_disable = "false"
    tls_cert_file = "/path/to/server-ca-bundle.pem"
    tls_key_file = "/path/to/server-key.pem"
}

disable_mlock = 1
api_addr = "https://127.0.0.1:28200"
cluster_addr = "https://127.0.0.1:28201"

Additional context None

[tyrannosaurus-becks]

@mikeadityas thanks for posting all this information! Since the error is coming back from the Alicloud API, my suspicion is that the access_key and secret_key in the configuration don't qualify to assume the role given in the role_arn.

To test the AssumeRole method during development, in RAM roles, this was the policy on the role being assumed, named "hastrustedactors":

{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::5138828231865461:root"
        ]
      }
    }
  ],
  "Version": "1"
}

And the role being used was:

vault write alibaba/role/role-based \
      role_arn='acs:ram::5138828231865461:role/hastrustedactors'

Would it be possible for you to check through that relationship more? Or to perhaps start with higher level permissions on the test pair, and then to back the permissions down to your current permission levels? Not sure what level of control you have in your test environment.

[mikeadityas]

@tyrannosaurus-becks thanks for the reply! Unfortunately, I still got the same error. As I mentioned earlier, I've tried using the same credentials on aliyun-cli and it generated the dynamic credentials without any problem.

[tyrannosaurus-becks]

Ah, so you're able to assume that role from the CLI? Is the CLI using the same Aliyun access key and secret key as is in the Vault config?

[mikeadityas]

Yes, the credentials used in CLI is the same as in the Vault config.

[heatherezell]

Hi folks! Is this still an issue in newer versions of Vault? Please let me know so I can bubble it up accordingly. Thanks!