Tool doesn't respect scopes set for designated application

[aeimer]

Please do not report security vulnerabilities here. The Responsible Disclosure Program details the procedure for disclosing security issues.

Thank you in advance for helping us to improve this library! Please read through the template below and answer all relevant questions. Your additional work here is greatly appreciated and will help us respond as quickly as possible. For general support or usage questions, use the Auth0 Community or Auth0 Support. Finally, to avoid duplicates, please search existing Issues before submitting one here.

By submitting an Issue to this repository, you agree to the terms within the Auth0 Code of Conduct.

Description

Provide a clear and concise description of the issue, including what you expected to happen.

With the release of 7.9.0 #495 introduced breaking behaviour for us.
We only deploy Hooks, Actions and Rules (including bindings and config etc) and the client for the management API only has these rights:

• read:rules
• update:rules
• create:rules
• read:rules_configs
• update:rules_configs
• read:hooks
• update:hooks
• create:hooks
• read:actions
• update:actions
• create:actions

That worked fine until now.
We currently see the following error in our pipeline:

[...]
2022-04-21T09:54:06.339Z - error: Problem running command import during stage processChanges when processing type logStreams
2022-04-21T09:54:06.339Z - error: Insufficient scope, expected any of: read:log_streams
2022-04-21T09:54:06.340Z - debug: Forbidden: Insufficient scope, expected any of: read:log_streams
    at /usr/local/lib/node_modules/auth0-deploy-cli/node_modules/rest-facade/src/Client.js:402:25
    at Request.callback (/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/superagent/lib/node/index.js:905:3)
    at /usr/local/lib/node_modules/auth0-deploy-cli/node_modules/superagent/lib/node/index.js:1126:20
    at IncomingMessage.<anonymous> (/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/superagent/lib/node/parsers/json.js:22:7)
    at Stream.emit (node:events:526:28)
    at Stream.emit (node:domain:475:12)
    at Unzip.<anonymous> (/usr/local/lib/node_modules/auth0-deploy-cli/node_modules/superagent/lib/node/unzip.js:53:12)
    at Unzip.emit (node:events:526:28)
    at Unzip.emit (node:domain:475:12)
    at endReadableNT (node:internal/streams/readable:1345:12)

We have nothing configured with streams and have set the "AUTH0_ALLOW_DELETE": false.

Reproduction

Detail the steps taken to reproduce this error, what was expected, and whether this issue can be reproduced consistently or if it is intermittent.

Where applicable, please include:

• Code sample to reproduce the issue
• Log files (redact/remove sensitive information)
• Application settings (redact/remove sensitive information)
• Screenshots

You should be able to reproduce it with any client that has not the right to read streams and no streams related config is set in the tenant yaml.

Environment

Please provide the following:

• Version of this library used:
• Version of the platform or framework used, if applicable:
• Other relevant versions (language, server software, OS, browser):
• Other modules/plugins/libraries that might be involved:

Problem occurred with 7.9.0

[willvedd]

Thanks for opening and apologies for the inconvenience. This tool currently operates under the assumption that you're managing all aspects of the tenant. As such, it's expected to grant nearly all permissions to the designated application in order to maintain parity. However, in your case I understand that you're only interested in managing a select few resources and by adding newer features that require additional scopes, this feels like a breaking change.

What is the desired behavior in your opinion? Do you expect the tool to skip any resource types that lack the sufficient scope for operation? This certainly seems like a reasonable proposal but it does increase the likelihood of unexpected outcomes if folks don't carefully manage those scopes; the occurrences of these "skips" would need to surfaced to the end user with some instruction on how to rectify.

Additionally, I ran a test with only the scopes you listed above and had a different set of issues. I am unable to confirm that the Deploy CLI would work with only those scopes prior to 7.9.0 unless there was some other type of configuration to exclude other resource types.

As far as a workaround goes, you're welcome to leverage the AUTH0_EXCLUDED configuration property adjacent to AUTH0_DELETE.

Example:

{
   ...
  "AUTH0_DELETE": false,
  "AUTH0_EXCLUDED": [
    "logStreams"
   ]
}

Of course in the above example, only log streams are excluded, but you're free to exclude all others besides actions, hooks, rules and rules configs.

[aeimer]

Hi @willvedd
so actually we got the recommendation of Auth0 support to use this tool in exactly that way. Also it makes sense in matter of this: https://www.cisa.gov/uscert/bsi/articles/knowledge/principles/least-privilege
Until that new version came up, all parts of the tool that we not used did not need even a read right, thats why my assumption was there is a bug in the new plugin.

Here my config, maybe that helps:

# gitlab ci
deploy:
  variables:
    AUTH0_CLIENT_SECRET: ''  # Set via CI vars
    AUTH0_ALLOW_DELETE: 'false'  # Just in addition to the config.json, as this allows to only update the pages
  script:
    # Install version >= 7.8.0 ; < 8.0.0
    - npm install -g auth0-deploy-cli@^7.8.0
    - a0deploy --version
    - time a0deploy import --config_file config.json --format yaml --input_file data/tenant.yaml --debug

# config.json
{
  "AUTH0_DOMAIN": "ourtenant.eu.auth0.com",
  "AUTH0_CLIENT_ID": "some_id",
  "AUTH0_CLIENT_SECRET": "",
  "AUTH0_KEYWORD_REPLACE_MAPPINGS": {
    "AUTH0_TENANT_NAME": "outenant",
    "AUTH_SERVICE_BASE_URL": "foo",
    "AUTH_SERVICE_SHARED_SECRET": "foo",
    "AUTH_LOG_COLLECTOR_BASE_URL": "foo",
    "AUTH_LOG_COLLECTOR_SECRET": "foo",
    "AUTH_SERVICE_CLIENTID": "foo"
  },
  "AUTH0_ALLOW_DELETE": false
}

# tenant.yaml
---
rules:
  - name: AuthServiceLogin
    script: ./rules/AuthServiceLogin.js
    stage: login_success
    enabled: true
    order: 12
rulesConfigs:
  # auth-service
  - key: AuthServiceBaseUrl
    value: @@AUTH_SERVICE_BASE_URL@@
  - key: AuthServiceSharedSecret
    value: @@AUTH_SERVICE_SHARED_SECRET@@
  # log-collector
  - key: AuthLogCollectorBaseUrl
    value: @@AUTH_LOG_COLLECTOR_BASE_URL@@
  - key: AuthLogCollectorSecret
    value: @@AUTH_LOG_COLLECTOR_SECRET@@
hooks:
  - name: inject-clients-tenant-and-application-id
    script: ./hooks/inject-clients-tenant-and-application-id.js
    dependencies: {}
    enabled: true
    secrets: {}
    triggerId: credentials-exchange
actions:
  - name: auth-action-checks
    code: ./actions/auth-action-checks/code.js
    dependencies:
      - name: axios
        version: 0.25.0
      - name: jsonwebtoken
        version: 8.5.1
    deployed: true
    runtime: node16
    secrets:
      - name: AUTH_SERVICE_BASE_URL
        value: @@AUTH_SERVICE_BASE_URL@@
      - name: AUTH_SERVICE_CLIENTID
        value: @@AUTH_SERVICE_CLIENTID@@
      - name: SHARED_SECRET
        value: @@AUTH_SERVICE_SHARED_SECRET@@
      - name: AUTH_LOG_COLLECTOR_BASE_URL
        value: @@AUTH_LOG_COLLECTOR_BASE_URL@@
      - name: AUTH_LOG_COLLECTOR_SECRET
        value: @@AUTH_LOG_COLLECTOR_SECRET@@
    status: built
    supported_triggers:
      - id: credentials-exchange
        version: v2
  - name: auth-action-login
    code: ./actions/auth-action-login/code.js
    dependencies:
      - name: url
        version: 0.11.0
      - name: jsonwebtoken
        version: 8.5.1
      - name: axios
        version: 0.25.0
      - name: uuid
        version: 8.3.2
    deployed: true
    runtime: node16
    secrets:
      - name: AUTH_SERVICE_BASE_URL
        value: @@AUTH_SERVICE_BASE_URL@@
      - name: SHARED_SECRET
        value: @@AUTH_SERVICE_SHARED_SECRET@@
      - name: AUTH_LOG_COLLECTOR_BASE_URL
        value: @@AUTH_LOG_COLLECTOR_BASE_URL@@
      - name: AUTH_LOG_COLLECTOR_SECRET
        value: @@AUTH_LOG_COLLECTOR_SECRET@@
    status: built
    supported_triggers:
      - id: post-login
        version: v2
  - name: check-limit-of-client-credential-grants
    code: ./actions/check-limit-of-client-credential-grants/code.js
    dependencies: []
    deployed: true
    runtime: node16
    secrets:
      - name: AUTH_SERVICE_BASE_URL
        value: @@AUTH_SERVICE_BASE_URL@@
      - name: AUTH_SERVICE_CLIENTID
        value: @@AUTH_SERVICE_CLIENTID@@
      - name: SHARED_SECRET
        value: @@AUTH_SERVICE_SHARED_SECRET@@
      - name: AUTH_LOG_COLLECTOR_BASE_URL
        value: @@AUTH_LOG_COLLECTOR_BASE_URL@@
      - name: AUTH_LOG_COLLECTOR_SECRET
        value: @@AUTH_LOG_COLLECTOR_SECRET@@
    status: built
    supported_triggers:
      - id: credentials-exchange
        version: v2
  - name: single-tenant-client-credential-grant
    code: ./actions/single-tenant-client-credential-grant/code.js
    dependencies:
      - name: request-promise
        version: 4.2.6
      - name: jsonwebtoken
        version: 8.5.1
    deployed: true
    runtime: node16
    secrets:
      - name: AUTH_SERVICE_BASE_URL
        value: @@AUTH_SERVICE_BASE_URL@@
      - name: SHARED_SECRET
        value: @@AUTH_SERVICE_SHARED_SECRET@@
      - name: AUTH_LOG_COLLECTOR_BASE_URL
        value: @@AUTH_LOG_COLLECTOR_BASE_URL@@
      - name: AUTH_LOG_COLLECTOR_SECRET
        value: @@AUTH_LOG_COLLECTOR_SECRET@@
    status: built
    supported_triggers:
      - id: credentials-exchange
        version: v2
triggers:
  credentials-exchange:
    - action_name: auth-action-checks
      display_name: auth-action-checks

[aeimer]

We also have a second project were we only deploy login-page and password-reset page, that still works fine. So thats really strange!

[willvedd]

@aeimer Totally agree about having the tool respect the scopes that are provisioned to the designated application. I believe the main reason it wasn't designed like that originally was due to time and simplicity.

We introduced a more intelligent method of scope detection in the latest 7.11.0 release. During the export/dump process, it will skip and warn when any resource lacks sufficient scope. Those configurations will have been omitted from being written to the configuration file, thereby being skipped on subsequent import/deploy. The only scope it truly requires is read:clients, but otherwise will respect all other scopes you set.

Please give it a shot and see if it suits your needs!

[aeimer]

@willvedd thank you! I just deployed our code without the logStreams:read grant, it worked!

Many thanks for the adaptions and effort!

[aeimer]

Ok, so actually we now get some weird 401s, but only in 9 of 10 deploys. We are not sure why this is the case... Even after adding read:clients the problems persists:

2022-04-29T15:40:18.057Z - debug: Start command import
2022-04-29T15:40:18.739Z - error: Problem running command import
2022-04-29T15:40:18.739Z - error: {"error":"server_error","error_description":"Request failed with status code 401"}
2022-04-29T15:40:18.741Z - debug: server_error: {"error":"server_error","error_description":"Request failed with status code 401"}
    at /auth0-deploy/a0deploy-cli/node_modules/rest-facade/src/Client.js:402:25
    at Request.callback (/auth0-deploy/a0deploy-cli/node_modules/superagent/lib/node/index.js:905:3)
    at /auth0-deploy/a0deploy-cli/node_modules/superagent/lib/node/index.js:1126:20
    at IncomingMessage.<anonymous> (/auth0-deploy/a0deploy-cli/node_modules/superagent/lib/node/parsers/json.js:22:7)
    at IncomingMessage.emit (node:events:532:35)
    at IncomingMessage.emit (node:domain:475:12)
    at endReadableNT (node:internal/streams/readable:1346:12)
    at processTicksAndRejections (node:internal/process/task_queues:83:21)

@willvedd can this be related to the changes that came with 7.10.0? I see the same problem before the release of 7.10.0...

[willvedd]

I think this may be due to insufficient scopes for triggers and/or actions. I'd ensure that you have sufficient create/update/delete scopes assigned for those resources. Because some resources have co-dependencies one other resources, it may be essential to grant slightly more permissions than you think you need. Although the intent of the feature was to make the export functionality more fault-tolerant, it doesn't ensure that every permutation of scopes will work as expected.

[aeimer]

@willvedd so what is the best way to find out the needed permissions?