Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

keystone: expect security check no admin-token to pass #191

Merged
merged 2 commits into from Mar 19, 2020

Conversation

fnordahl
Copy link
Contributor

Also add test to validate that the domain named default
literally has an ID of default.

Also add test to validate that the domain named ``default``
literally has an ID of ``default``.
A side effect of migrating to bootstrapping Keystone as opposed
to using the admin_token is that the charm credentials is now
subject to the Keystone policy.

At present the ``list_services`` policy is used as a test of the
Policy Override feature, however revoking access to said call
will make the charm go into an error state as it attempts to use
it as part of managing the Keystone CRUD.

Change the test to use the ``list_credentials`` policy for test
instead.
Copy link
Contributor

@thedac thedac left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good, but should we wait until the keystone change is fully ready to land?

openstack-gerrit pushed a commit to openstack/charm-keystone that referenced this pull request Mar 18, 2020
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: openstack-charmers/zaza-openstack-tests#191
Change-Id: I23940720c24527ee34149f035c3bdf9ff54812c9
openstack-gerrit pushed a commit to openstack/openstack that referenced this pull request Mar 18, 2020
* Update charm-keystone from branch 'master'
  - Merge "Replace use of admin_token with Keystone bootstrap"
  - 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: openstack-charmers/zaza-openstack-tests#191
    Change-Id: I23940720c24527ee34149f035c3bdf9ff54812c9
@ChrisMacNaughton ChrisMacNaughton merged commit 7418d00 into master Mar 19, 2020
@ajkavanagh ajkavanagh deleted the keystone-remove-admin-token branch July 13, 2021 10:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants