summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* Merge "Only log warnings about token length when length exceeds ↵stable/wallabyZuul2022-11-043-4/+68
|\ | | | | | | max_token_size" into stable/wallaby
| * Only log warnings about token length when length exceeds max_token_sizeLance Bragstad2022-07-263-4/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, the fernet token provider would log warnings when a fernet token exceeded 255 characters, which is common for LDAP-backed deployments. The warning is always issued, even when operators configure keystone's max_token_size to a higher value, causing confusion because it appears the configuration value is silently ignored. This commit fixes that issue by using the max_token_size configuration parameter consistently in the fernet token provider. Closes-Bug: 1926483 Change-Id: I4bb54aac9b950d59082a4468203a3249790839d7 (cherry picked from commit 68bfb685d12937dde11d1a335bd992203ec7c293)
* | Move fips job to centos-9Ade Lee2022-09-191-2/+4
| | | | | | | | | | | | | | | | | | Move FIPS job to centos 9 and add new required nslookup_target variable. Change-Id: Ifef262cfca4ecb8ad1222da3c43e5749f40c1f24 (cherry picked from commit 950dd5e5032afd73527c82c6ce63ee2ad94dc252) (cherry picked from commit 1daa8e70c943d5b0723f5cf821db99539cef0a15) (cherry picked from commit 4799025f5755e31f8cb44fa8b34ff465aba27635)
* | Merge "Fix host:port handling" into stable/wallabyZuul2022-09-161-2/+4
|\ \
| * | Fix host:port handlingBence Romsics2022-09-081-2/+4
| |/ | | | | | | | | | | | | | | | | | | | | | | When we check the EC2 signature without the port part of the host value received, we should properly split host:port. Keep in mind the splitting should work for values like [fc00::]:123 too. Change-Id: I1d90dfcea3568e2a9b22069daa428ea6a2a38bd6 Closes-Bug: #1988168 (cherry picked from commit 6c35b366e3c8c6d7f47471b93f5315582301c5ef) (cherry picked from commit d39790ac4e9dc25af09cdddc6217e36bacbc2bb1) (cherry picked from commit 0bb9cdee71805af1a7cb0a7db110b336eae5da1e)
* | Merge "Fix bindep.txt for current RPM based distributions" into stable/wallabyZuul2022-09-161-3/+1
|\ \ | |/ |/|
| * Fix bindep.txt for current RPM based distributionsGrzegorz Grasza2022-03-291-3/+1
| | | | | | | | | | | | | | | | Currently rpm based distributions all use python3-devel. Tested this with centos7 rhel7 rhel8 fedora35. Change-Id: I9a8e6285edbb3799cf552acf479598b3b6c63b99 (cherry picked from commit 0eba22f331f5e998d5cdee2039e8f14772e78e5e)
* | Merge "Remove the note of training-labs" into stable/wallabywallaby-em19.0.1Zuul2022-07-213-24/+0
|\ \
| * | Remove the note of training-labsHan Guangyu2022-04-223-24/+0
| |/ | | | | | | | | | | | | | | | | | | | | | | Training-labs had been officially retired as no maintainer. The information of training-labs has been deleting in the openstack documentatioan. It is not appropriate to continue the presentation in note form here. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-October/025586.html [2] https://opendev.org/openstack/training-labs/commit/e78d74f10558ab3e6a9a6fd7d45e617c15e9c3d8 Change-Id: I0ac3d05389041ac58fe2347171541ffaaf151fdf
* | Merge "Wallaby-only: Fix wrong python job template used" into stable/wallabyZuul2022-07-201-1/+1
|\ \
| * | Wallaby-only: Fix wrong python job template usedTakashi Kajinami2022-05-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | We should use the template corresponding to the release. This change replaces the wrong template(victoria template) by the appropriate one (wallaby template). Change-Id: Ic25357863b78c0e5c11cbd0e0da1dbd3e4099519
* | | Merge "Add FIPS check job" into stable/wallabyZuul2022-07-152-0/+15
|\ \ \ | |/ / |/| |
| * | Add FIPS check jobAde Lee2022-02-042-0/+15
| |/ | | | | | | | | | | | | | | | | Testing a new FIPS enabled gate job here. This job will be for Centos 8 with FIPS enabled. This will use a playbook in the zuul-jobs repo to enable FIPS. Change-Id: I3187971a14b38c7ca3bb64bdd3d18c64709c466f (cherry picked from commit 50f0a50cf4d52d3f61b64713bd4faa7a4626ae53)
* | Fix issue with LDAP backend returning bytes instead of stringGrzegorz Grasza2022-02-071-2/+17
|/ | | | | | | | | | | | | | When connecting to some LDAP server software, the ldap client returns bytes instances instead of the expected strings. This can result in either being transparently converted to strings, when the data is inserted via sqlalchemy into the database, or could be used as input to other functions, and/or cached, which causes unexpected results. Closes-Bug: #1952458 Resolves: rhbz#1964872 Change-Id: I77148641715efe09e3adc2e9432e66e50fb444b4 (cherry picked from commit 1e0cd90191663c100c165d4c6a2b1ca796b5af25)
* Merge "Update local_id limit to 255 characters" into stable/wallabyZuul2021-10-269-3/+120
|\
| * Update local_id limit to 255 charactersGrzegorz Grasza2021-08-279-3/+120
| | | | | | | | | | | | | | | | | | | | | | This avoids the "String length exceeded." error, when using LDAP domain specific backend in case the user uses a user id attribute, which can exceed the previous constraint of 64 chars. Change-Id: I923a2a2a5e79c8f265ff436e96258288dddb867b Closes-Bug: #1929066 Resolves: rhbz#1959345 (cherry picked from commit ce6031ca12156620cec214a49d162ec7bb30752f)
* | Merge "Fix typos in application credential policies" into stable/wallabyZuul2021-10-111-2/+2
|\ \
| * | Fix typos in application credential policiesLance Bragstad2021-10-071-2/+2
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We updated these policies when we introduces system scope and default roles, but the policy names accidentally changed, which makes the policy files render with an alias because oslo.policy thinks the names are changing. Conflicts: keystone/common/policies/application_credential.py in later releases the deprecated parameters were moved from the DocumentedRuleDefault object to the DeprecatedRule object, which is a non-functional change. Change-Id: I1121f1abe769ee83ffc285103a95ee95540ce727 (cherry picked from commit 60e898c47038667e66a54e0a9a6cd7b91e115f55) (cherry picked from commit 7b28f1b3b47d0e4a22afe99c64d047016a772da5)
* | Merge "Fix typos in ec2 credential policies" into stable/wallabyZuul2021-10-081-6/+6
|\ \
| * | Fix typos in ec2 credential policiesLance Bragstad2021-10-071-6/+6
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | There was a trailing s in two of these policies and it caused the policy names to mismatch, which causes confusion with the rendered policy files and potentially causes uses with deprecation logic. Conflicts: keystone/common/policies/ec2_credential.py in later releases the deprecated parameters were moved from the DocumentedRuleDefault object to the deprecated object. Change-Id: I54021986d17c57d7733d53caa4032c2767eaf25e (cherry picked from commit 82da8824df0f56ef4e137805bf32d647cef1ea59) (cherry picked from commit 6dff22b5baa1a19842aca435782fe1f9789f72cc)
* | Merge "Fix typo in identity provider policies" into stable/wallabyZuul2021-10-071-4/+4
|\ \
| * | Fix typo in identity provider policiesLance Bragstad2021-10-071-4/+4
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | This cause the sample generated policy file to alias the old name with the new policy name, which isn't needed since we're not renaming these policies at all and it was likely a typo. Conflicts: keystone/common/policies/identity_provider.py In later releases the deprecation parameters were moved up to the deprecated options and not in the DocumentedRule defaults. Change-Id: Idfd9adbbe800bbc21814d94002a2b61524cce28a (cherry picked from commit c10d5c88ef40e63d4dfefb792d6c3d68acd72dd9)
* | Merge "Update TOX_CONSTRAINTS_FILE for stable/wallaby" into stable/wallabyZuul2021-10-071-3/+3
|\ \
| * | Update TOX_CONSTRAINTS_FILE for stable/wallabyOpenStack Release Bot2021-03-261-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Update the URL to the upper-constraints file to point to the redirect rule on releases.openstack.org so that anyone working on this branch will switch to the correct upper-constraints list automatically when the requirements repository branches. Until the requirements repository has as stable/wallaby branch, tests will continue to use the upper-constraints list on master. Change-Id: Idd89731aaf3138bb400182f5852a85ad23ea309d
* | | Merge "Update .gitreview for stable/wallaby" into stable/wallabyZuul2021-10-071-0/+1
|\ \ \ | |/ / | | / | |/ |/|
| * Update .gitreview for stable/wallabyOpenStack Release Bot2021-03-261-0/+1
| | | | | | | | Change-Id: I6624fb2b4299aba328b02a870722ed60c89876a6
* | Hide AccountLocked exception from end usersGage Hugo2021-05-104-6/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change hides the AccountLocked exception from being returned to the end user to hide sensitive information that a potential malicious person could gain insight from. The notification handler catches the AccountLocked exception as before, but after sending the audit notification, it instead bubbles up Unauthorized rather than AccountLocked. Co-Authored-By: Samuel de Medeiros Queiroz <samueldmq@gmail.com> Change-Id: Id51241989b22c52810391f3e8e1cadbf8613d873 Related-Bug: #1688137 (cherry picked from commit ac2631ae33445877094cdae796fbcdce8833a626)
* | Retry update_user when sqlalchemy raises StaleDataErrors19.0.0.0rc219.0.0Lance Bragstad2021-03-293-0/+52
|/ | | | | | | | | | | | | | | | | | | | | | | Keystone's update_user() method in the SQL driver processes a lot of information about how to update users. This includes evaluating password logic and authentication attempts for PSI-DSS. This logic is evaluated after keystone pulls the user record from SQL and before it exits the context manager, which performs the write. When multiple clients are all updating the same user reference, it's more likely they will see an HTTP 500 because of race conditions exiting the context manager. The HTTP 500 is due to stale data when updating password expiration for old passwords, which happens when setting a new password for a user. This commit attempts to handle that case more gracefully than throwing a 500 by detecting StaleDataErrors from sqlalchemy and retrying. The identity sql backend will retry the request for clients that have stale data change from underneath them. Change-Id: I75590c20e90170ed862f46f0de7d61c7810b5c90 Closes-Bug: 1885753 (cherry picked from commit ceae3566e83b26fd6a1679154eae9b0cef29da64)
* Merge "Add job for keystone functional protection tests"19.0.0.0rc1Zuul2021-03-031-11/+2
|\
| * Add job for keystone functional protection testsLance Bragstad2021-03-021-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | This commit introduces a new check and gate job for keystone to use the functional RBAC tests in keystone-tempest-plugin. These tests were derived from keystone's original protection tests, but they use tempest and they're re-useable for people looking to validate secure RBAC functionality in their own deployments. Depends-On: https://review.opendev.org/#/c/686305/ Change-Id: I813cff07c20fcba1aaec6a5e68014a2a9eb9462e
* | Merge "fix E225 missing whitespace around operator"Zuul2021-02-281-1/+1
|\ \
| * | fix E225 missing whitespace around operatorMaurice Escher2020-11-271-1/+1
| | | | | | | | | | | | Change-Id: I960379ceb435472cdc754b5f63243c70d552d9c3
* | | Merge "trivial: Update minor wording nit in RBAC persona documentation"Zuul2021-02-271-2/+2
|\ \ \
| * | | trivial: Update minor wording nit in RBAC persona documentationLance Bragstad2021-02-051-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After reading through the documentation, I thought this sentence sounded funny using 'within' and 'in' so close to each other. I updated it so that it isn't quite so jarring. Change-Id: I2619108216035a37823e53efb5a3f9fe6cfe5cbb
* | | | Merge "Clarify top-level personas in RBAC documentation"Zuul2021-02-271-13/+69
|\ \ \ \ | |/ / /
| * | | Clarify top-level personas in RBAC documentationLance Bragstad2021-02-051-13/+69
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit updates the documentation for service api protection to better describe the overall personas for system, domain, and project users. It also adds some examples that show operators how to list users with all role assignments on a particular target, which include a superset of the existing examples. Change-Id: I40dd33fc0afa0240c6b1cd48322fd988fc5524af
* | | | Merge "Clarify ``reader`` role implementation in persona admin guide"Zuul2021-02-271-28/+67
|\ \ \ \ | |/ / /
| * | | Clarify ``reader`` role implementation in persona admin guideLance Bragstad2021-02-051-28/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The secure RBAC work propogating throughout the community has led to some interesting discussions about how to implement support for ``reader``. Specifically, should ``reader`` be used for auditing deployments? Some compliance targets, verified by third-party auditors, require access to sensitive information (e.g., thinking about license keys in glance images or volume type encryption metadata in cinder). The concern raised among developers updating their default policies to use ``reader`` roles is if they should be using that role to protect sensitive information, especially if it's the least-authoritative role in the hierarchy between reader, member, and admin. This documentation is supposed to assist deployers in understanding the various personas that developers are implementing by default, but it doesn't call out the complicated relationship we have with ``reader`` and auditing. The change here proposes that we explicitly say that ``reader`` shouldn't be used to protect sensitive information, regardless of the scope, because ``reader`` was designed to be the least-authoritative role provided by keystone, by default. Instead, service developers working to implement these personas consistently in other services should keep sensitive information, if applicable to their API or resources, at the ``admin`` tier of the hierarchy. This provides better protection of sensitive information by not exposing is implicitly. We can consider supporting a formal default role for auditing in the future, but building it outside the default implied role tree so that it's not implied to anyone with a role assignment. This will come at another time and we can use implied roles to re-use all the work we've done across OpenStack to implement support for ``reader``. For now, ``reader`` should be viewed from the perspective of the least-authoritative permissions grant-able to a given scope (e.g., system, domain, or project). Even if ``reader`` has limited use in auditing deployments, it's still incredibly useful for operators because they have a role they can grant to users with minimal trust, or minimal permissions in the deployment. This commit acknowledges the use-case for an elevated auditor role and that it's something we can implement as a formal role in keystone in the future. Change-Id: Iea28faf1b3e63c7ab07e90808d2bc76ee3ee0612
* | | | Merge "Use enforce_new_defaults when setting up keystone protection tests"Zuul2021-02-051-1/+1
|\ \ \ \
| * | | | Use enforce_new_defaults when setting up keystone protection testsLance Bragstad2020-10-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `keystone.conf [oslo_policy] enforce_new_defaults` option is meant to help deployments that want to opt into the new policy enforcement model (with scope checking) but without having to generate override files. This is the case for devstack and tempest. We can use this to bypass generating a policy file with just the new policies for tempest testing. Change-Id: I3b219bde569c5a8001aec0c243027b6881254304
* | | | | Merge "Ignore oslo.db deprecating sqlalchemy-migrate warning"Zuul2021-02-051-0/+3
|\ \ \ \ \
| * | | | | Ignore oslo.db deprecating sqlalchemy-migrate warningMike Bayer2021-01-261-0/+3
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In I59335b4f318bae2e29ab139cdea089a4d6e14305, oslo.db is now emitting deprecation warnings for SQLAlchemy-migrate functions. This breaks Keystone tests which raise on DeprecationWarning, so add to the filters. Change-Id: I42f0abc2ddf8c53239d5098d5f32b667314b942d
* | | | | Merge "[goal] Deprecate the JSON formatted policy file"Zuul2021-02-0513-21/+68
|\ \ \ \ \
| * | | | | [goal] Deprecate the JSON formatted policy fileGhanshyam Mann2021-02-0113-21/+68
| | |_|/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As per the community goal of migrating the policy file the format from JSON to YAML[1], we need to do two things: 1. Change the default value of '[oslo_policy] policy_file'' config option from 'policy.json' to 'policy.yaml' with upgrade checks. 2. Deprecate the JSON formatted policy file on the project side via warning in doc and releasenotes. Also replace policy.json to policy.yaml ref from doc and tests. [1]https://governance.openstack.org/tc/goals/selected/wallaby/migrate-policy-format-from-json-to-yaml.html Change-Id: Ic65d2fd6ce7215b4a47a6fb41b9cbf991f27773b
* | | | | Merge "Support bytes type in generate_public_ID()"Zuul2021-02-023-2/+35
|\ \ \ \ \ | |/ / / / |/| | | |
| * | | | Support bytes type in generate_public_ID()Keigo Noha2021-01-113-2/+35
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | python-ldap3.0 or later running on python3 uses str or bytes data type according to what fields are returned. local_id may be a bytes data type. To handle it properly, mapping[key] needs to be examined for identifying its data type and what python version is used. Closes-Bug: #1901654 Change-Id: Iac097235fd31e166028c169d14ec0937c663c21c
* | | | Add openstack-python3-wallaby-jobs-arm64 jobricolin2021-01-191-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a non-voting job to validate py3 unittests on ARM64 Task: 40403 Story: 2007938 Change-Id: Ibb82d65784368ff82588d6879111cb6c7eb780ca
* | | | Merge "Use app cred user ID in policy enforcement"Zuul2021-01-113-2/+118
|\ \ \ \
| * | | | Use app cred user ID in policy enforcementLance Bragstad2020-11-113-2/+118
| |/ / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The application credential policies use the `rule:owner` policy to allow users to manage their own credentials. The policy engine pulled the user_id attribute from the request path instead of the actual application credential. This allowed for users to exploit the enforcement and view or delete application credentials they don't own. This commit attempts to resolve the issue by updating the flask parameters before they're translated to policy arguments and target data, prior to policy enforcement. Change-Id: I903d20fa41270499ca1c39d296120dd97cef5405 Closes-Bug: 1901207
* | | | Imported Translations from ZanataOpenStack Proposal Bot2021-01-094-327/+138
| | | | | | | | | | | | | | | | | | | | | | | | | | | | For more information about this automatic import see: https://docs.openstack.org/i18n/latest/reviewing-translation-import.html Change-Id: Ic8c9b155a20aea11f74794aeb45a4e92e632148a
View Lorry Controller Status