OpenStack Keystone Charm

[RFE] system scope and scoped RBAC: support enforce_scope on Queens+ deployments

Bug #1774733 reported by Dmitrii Shcherbakov on 2018-06-01

This bug affects 1 person

Affects		Status	Importance	Assigned to	Milestone
	OpenStack Keystone Charm	Triaged	Wishlist	Unassigned

Bug Description

Upstream Keystone is progressing with better scoping of tokens and policies to address the following bugs:

https://bugs.launchpad.net/keystone/+bug/968696
https://bugs.launchpad.net/keystone?field.searchtext=the+v3+for+different+scopes&search=Search&field.status%3Alist=NEW&field.status%3Alist=INCOMPLETE_WITH_RESPONSE&field.status%3Alist=INCOMPLETE_WITHOUT_RESPONSE&field.status%3Alist=CONFIRMED&field.status%3Alist=TRIAGED&field.status%3Alist=INPROGRESS&field.status%3Alist=FIXCOMMITTED&field.assignee=&field.bug_reporter=&field.omit_dupes=on&field.has_patch=&field.has_no_package=

As of keystone there is now a "system" scope in addition to domain and project-level scopes.

Over time charms need to be converted to support setups with system scope admins where enforce_scope option is set to True:
https://docs.openstack.org/releasenotes/oslo.policy/queens.html#new-features

https://blueprints.launchpad.net/keystone/+spec/system-scope
https://specs.openstack.org/openstack/oslo-specs/specs/queens/include-scope-in-policy.html

It will also require modifications of default policy files or their modification/removal in favor of policy-in-code approach with customizations handled by:

1) policy.json/yaml customization via policy_dirs https://bugs.launchpad.net/charm-keystone/+bug/1741723

(discontinued)
2) verb + URL API-based checks for scoped RBAC https://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/role-check-from-middleware.html

Currently we hard-code admin_domain_id and service_tenant_id for policy rules while we could simply use system-scoped admin roles in the future.
https://github.com/openstack/charm-keystone/blob/master/templates/ocata/policy.json#L3-L4

`keystone-manage bootstrap` as of Queens
https://github.com/openstack/keystone/commit/3c524e6491c1b35a2f8413ebe046c238bf530d71

https://docs.openstack.org/releasenotes/keystone/queens.html#new-features
"Keystone now supports the ability to assign roles to users and groups on the system. As a result, users and groups with system role assignment will be able to request system-scoped tokens. Additional logic has been added to keystone-manage bootstrap to ensure the administrator has a role on the project and system."

See original description

Dmitrii Shcherbakov (dmitriis) on 2018-06-01

description:

updated

Revision history for this message

Dmitrii Shcherbakov (dmitriis) wrote on 2018-06-13:

Download full text (8.3 KiB)

An example of how to create a system-scoped token via keystone API (openstack client support seems to be missing at the time of writing) with a notably different scope section in the request:

An example of how to create a system-scoped token via keystone API (openstack client support seems to be missing at the time of writing) with a notably different scope section in the request:

cat > token-request.json 
{
    "auth": {
        "identity": {
            "methods": [
                "password"
            ],
            "password": {
                "user": {
                    "domain": {
                        "name": "admin_domain"
                    },
                    "name": "admin",
                    "password": "t0ughpasswd"
                }
            }
        },
        "scope": {
            "project": {
                "domain": {
                    "name": "admin_domain"
                },
                "name": "admin"
            }
        }
    }
}

curl -si -d @token-request.json -H "Content-type: application/json" http://10.232.6.4:5000/v3/auth/tokens | awk '/X-Subject-Token/ {print $2}'
1374d65b4bd04f29bcd888af7c3a7568

curl -s -H"X-Auth-Token:1374d65b4bd04f29bcd888af7c3a7568" http://10.232.6.4:5000/v3/auth/system | jq
{
  "system": [],
  "links": {
    "self": "http://10.232.45.175:5000/v3/auth/system"
  }
}

curl -X PUT -s -H"X-Auth-Token:1374d65b4bd04f29bcd888af7c3a7568" http://10.232.6.4:5000/v3/system/users/c35ddbaea658492baa16c7e15a14320f/roles/2c998c11b22d40cd98e617060447579e | jq

curl -s -H"X-Auth-Token:1374d65b4bd04f29bcd888af7c3a7568" http://10.232.6.4:5000/v3/auth/system | jq
{
  "system": [
    {
      "all": true
    }
  ],
  "links": {
    "self": "http://10.232.45.175:5000/v3/auth/system"
  }
}

cat > usera-token-request.json
{
    "auth": {
        "identity": {
            "methods": [
                "password"
            ],
            "password": {
                "user": {
                    "domain": {
                        "name": "a"
                    },
                    "name": "usera",
                    "password": "test"
                }
            }
        },
        "scope": {
		"system": {
		      "all": true
		}
        }
    }
}

curl -si -d @usera-token-request.json -H "Content-type: application/json" http://10.232.6.4:5000/v3/auth/tokens | awk '/X-Subject-Token/ {print $2}'
365aa5b8c9b4417e9c6e0ad3b12ea2c1

curl -s -H"X-Auth-Token:365aa5b8c9b4417e9c6e0ad3b12ea2c1" http://10.232.6.4:5000/v3/auth/system | jq
{
  "system": [
    {
      "all": true
    }
  ],
  "links": {
    "self": "http://10.232.45.175:5000/v3/auth/system"
  }
}

Revision history for this message

Frode Nordahl (fnordahl) wrote on 2018-08-21:

This is indeed good input. We will probably revisit this as we approach reworking how Keystone is bootstrapped in the charm.

Changed in charm-keystone:
status:	New → Triaged
importance:	Undecided → Wishlist

Dmitrii Shcherbakov (dmitriis) on 2018-12-11

description:

updated

Revision history for this message

OpenStack Infra (hudson-openstack) wrote on 2020-03-18: Related fix merged to charm-keystone (master)

Reviewed: https://review.opendev.org/712040
Committed: https://git.openstack.org/cgit/openstack/charm-keystone/commit/?id=0a02c30fe5f4650235519897b71588ae22fa0971
Submitter: Zuul
Branch: master

commit 0a02c30fe5f4650235519897b71588ae22fa0971
Author: Frode Nordahl <email address hidden>
Date: Mon Mar 9 15:06:09 2020 +0100

Replace use of admin_token with Keystone bootstrap

    Stop the use of the admin_token and use the bootstrap process
    to initialize Keystone instead. Fortunately the implementation
    of the bootstrap process is both idempotent when it needs to be
    and it can be safely called on an existing deployment.

    Subsequently we can migrate by just removing the admin_token
    from the configuration and create new credentials for use by
    the charm with a call to ``keystone-manage bootstrap``.

    Remove configuration templates for versions prior to Mitaka, by
    doing this we need to move any configuration initially defined
    prior to Miataka forward to the ``templates/mitaka`` folder.

    A side effect of this migration is that newly bootstrapped
    deployments will get their ``default`` domain created with a
    literal ID of ``default``. Prior to this change third party
    software making assumptions about that being the case may have
    had issues.

    Closes-Bug: #1859844
    Closes-Bug: #1837113
    Related-Bug: #1774733
    Closes-Bug: #1648719
    Closes-Bug: #1578678
    Func-Test-Pr: https://github.com/openstack-charmers/zaza-openstack-tests/pull/191
    Change-Id: I23940720c24527ee34149f035c3bdf9ff54812c9

Report a bug

This report contains Public information

Everyone can see this information.

You are

Subscribing...

Edit bug mail

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.