This change addresses several issues in the creation and use of EC2/S3
credentials with keystone tokens.
1. Disable altering credential owner attributes or metadata
Without this patch, an authenticated user can create an EC2 credential
for themself for a project they have a role on, then update the
credential to target a user and project completely unrelated to them. In
the worst case, this could be the admin user and a project the admin
user has a role assignment on. A token granted for an altered credential
like this would allow the user to masquerade as the victim user. This
patch ensures that when updating a credential, the new form of the
credential is one the acting user has access to: if the system admin
user is changing the credential, the new user ID or project ID could be
anything, but regular users may only change the credential to be one
that they still own.
Relatedly, when a user uses an application credential or a trust to
create an EC2 credential, keystone automatically adds the trust ID or
application credential ID as metadata in the EC2 access blob so that it
knows how the token can be scoped when it is used. Without this patch, a
user who has created a credential in this way can update the access blob
to remove or alter this metadata and escalate their privileges to be
fully authorized for the trustor's, application credential creator's, or
OAuth1 access token authorizor's privileges on the project. This patch
fixes the issue by simply disallowing updates to keystone-controlled
metadata in the credential.
2. Respect token roles when creating EC2 credentials
Without this patch, a trustee, an application credential user, or an
OAuth1 access token holder could create an EC2 credential or an
application credential using any roles the trustor, application
credential creator, or access token authorizor had on the project,
regardless of whether the creator had delegated only a limited subset of
roles. This was because the trust_id attribute of the EC2 access blob
was ignored, and no metadata for the application credential or access
token was recorded either. This change ensures that the access
delegation resource is recorded in the metadata of the EC2 credential
when created and passed to the token provider when used for
authentication so that the token provider can look up the correct roles
for the request.
Change-Id: I39d0d705839fbe31ac518ac9a82959e108cb7c1d
Closes-bug: #1872733
Closes-bug: #1872755
Closes-bug: #1872735
The mock library is a third party lib that attempted to bridge the gap
between Python 2 and Python 3 mocking. Now that we have moved to py3
only, there is no need to use a third party lib and we can use the
standard built-in mocking support.
Change-Id: I8bbcedb7ad3f0bc2e06dfa13878a97411ee1dc6d
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This repo does not support Python 2 anymore, so we don't need
six for compatibility between Python2 and 3, convert six usage to Python
3 code.
Change-Id: Icba56808f38277b27af2ae5aac4b8507dee71b3b
This change adds tests cases for the default roles keystone
supports at install time. It also modifies the policies for the
credentials API to be more self-service by properly checking
for various scopes.
Closes-Bug: 1788415
Partial-Bug: 968696
Change-Id: Ifedb7798c96930b6cc0f91159a14a21ac4b02f9f
Convert S3 and EC2 auth to flask native dispatching.
Test changes required:
* Eliminate direct reference of the EC2 / S3 controllers, originally
this direct reference was to verify signature checking. Since
signature checking is an @staticmethod now, direct reference of
the API resources covers everything.
* Direct import of keystone.common.controller - due to an oddity in
how our WSGI code work(s) in test, if nothing imports the common
controller module, the tests fail using the oslo import_class
mechanism.
Change-Id: I06e95957b3ea3a55b0da28959548bd5eb628c70b
Partial-Bug: #1776504
Then `enable` config option of trust feature is depreacted in
Queens. Remove it in Rocky now.
Change-Id: I186b49471cb774e161ff4c35c9879a0a4fa9538f
bp: removed-as-of-rocky.
A previous change started remove the self magic:
Ic2094dca56158d8e4cd843eadff837f3a17ea38f
This commit finishes that work. A subsequent patch will remove the
self manager logic all together and we'll fix up any trivial test
infrastructure then.
Change-Id: Iedbde34ef5aa84905fd6b5f2297bf7f46dd7d278
This commit implements credential encryption through the following changes:
- additive schema change to store key hashes for credentials
- database migration to encrypt all pre-existing credentials
- contractive schema change to remove unencrypted credential column
- added code to the credential Manager to handle credential encryption
All credentials will be encrypted by default. There will not be a way to store
unencrypted credentials in keystone from this point forward.
Note that this implementation uses database triggers in the migration process.
If operators use the traditional offline migration method, it would be more
reliable if we didn't try to setup and tear down triggers, as they'll never be
used anyway. This makes it so that expand and contract migrations can skip
anything related to triggers.
Co-Authored-By: Werner Mendizabal <nonameentername@gmail.com>
bp credential-encryption
Depends-On: I433da9a257daa21ec3b5996b2bca571211f1fbba
Depends-On: Id3e8922adc154cfec5f7a36613e22eb0b49eeffe
Change-Id: I31b7539db436ad270462cfaa3b14213e0ed1fc04
It was possible to create a credential without providing a project_id
and later updating it to the ec2 type.
This patch fixes the issue by adding a manual checking in the
manager layer since it needs to check the old credential contents
prior failing the request.
Change-Id: I1eb28a46c89e17d9c990cc798867d1a59714fe5f
Closes-Bug: #1613466
keystone.common.config is 1200+ lines of super dense, merge-conflict
prone, difficult to navigate, and finicky to maintain code. Let's follow
nova's lead and break it down into more manageable modules.
This patch creates a new Python package, keystone.conf, and moves all of
our configuration options into it, mirroring nova's nova.conf package.
There are a couple special modules in keystone.conf introduced here as
well:
- keystone.conf.__init__: This causes all of Keystone options to be
registered on import, so consumers of keystone.conf don't have
races with config initialization code while trying to use
oslo_config.cfg.CONF directly (keystone.conf replaces all uses for
oslo_config.cfg.CONF in keystone).
- keystone.conf.base: Keystone's [DEFAULT] group options. I'd prefer
this to be called 'default.py', but I'm just copying nova's lead here.
- keystone.conf.opts: The entry point for oslo.config itself.
- keystone.conf.constants: There are a few constants (deprecation
messages, default paths, etc) that are used by multiple configuration
modules, so they need to live in a common place.
Change-Id: Ia3daffe3fef111b42de203762e966cd14d8927e2
Keystone's tox.ini contains an "ignore" entry for H405 violations:
multi line docstring summary not separated with an empty line.
All violations of H405 should be fixed so that H405 can be removed
from the ignore list.
Change-Id: I1b2aae0cabc20909cf3b0a405d5e31c5d91148b2
Closes-Bug: #1482773
Deprecate the admin_token_auth middleware in favor of using
keystone-manage bootstrap
Change-Id: Ib4ca153af2855911f9261081e7e442dfbc28f652
bp: deprecated-as-of-mitaka
bp: bootstrap
When getting, or operating on a credential, EC2 controller needs to
specify it's a ec2 credential, avoiding conflicts with other type of
credentials.
Closes-Bug: #1506473
Change-Id: Id92fc87bf1be5448aa929224bbce4d3f7f4359b6
Standardize use of unit.new_credential_ref(). Remove methods in preference
for the common function.
Refactor the credential creation code to simplify and standardize the tests.
Change-Id: I4274ea9ae17ae7b8b18dc0c86c9f9496a0803c71
Replace all hand created user refs with calls to new_user_ref().
Note: LDAP live testing code will be updated in a follow on patch.
They require more testing before submission.
Change-Id: I73b1d869534ac3a1bcd2404ef1dd3a0d5b7ea518
The name of this method has plagued me for years, so I figured I would
finally propose a fix. The reason v3_authenticate_token() is a terrible
name is that it implies that a token is being authenticated (in other
words: validated). As it turns out, we have another operation that
validates tokens, and this isn't it.
By renaming the method to v3_create_token() there is absolutely no
confusion about the intended outcome. This also more closely reflects
how we colloquially refer to operation.
v3_authenticate() might have also have been an improvement, but could
lead to the same confusion we have today (whether or not the user is
authenticating with keystone or whether a service is authenticating a
token).
Change-Id: I2bfebf1b48de07e81eadc2782d4e975b920f2a6a
Some tests used incorrect order assertEqual(observed, expected).
The correct order expected by testtools is
assertEqual(expected, observed).
At some places, corrected argument order for assertNotEqual method as well.
Change-Id: I6d63e77620b8dd9d6415424783b99a7e2e381a22
Partial-Bug: #1259292
This patch replace the hard coded HTTP error code (200~226)
in unittest with the constants, and remove part of them which
has the same value with the default value.
Change-Id: I184adc72772a030b3a316b1e3f9676d0efc807b5
Currently the only attribute that you can filter a credential list by is
user_id. I want to be able to list by user_id and credential type (a
required field) so that I only get back my EC2 credentials (for example)
when I do a list.
Change-Id: I91f8fb15a2e9a8326059d7a60d2bf1b4c4aa6daa
Closes-bug: #1460492
bp list-credentials-by-type
ec2 tokens cannot be created without the user and project
associated with the credentials. The project_id must be
required when creating ec2 credentials.
Updating json schema to check:
- if ec2 type, project_id is required
- else, project_id is optional
Closes-Bug: #1268977
Change-Id: Id7118e028d8c3ff607ac24cd9ecba90a905ce91f
Keystone modules used different sources of the CONF global so were
inconsistent. All modules should use CONF from oslo_config.cfg.
Change-Id: I60c8d2c577d37b9b8a367b46596154ce6c49fff4
The existing test files are all moved under keystone.tests.unit,
except the existing keystone.tests.unit are left in place.
The .testr.conf is updated so that unit tests are run by default
in tox envs, and a tox env can override the tests to run by
setting OS_TEST_PATH.
This is so functional tests can sit in keystone.tests.functional.
Change-Id: I065d3f56e22f344abdadd92b3b384b002b02d989
Vishakha Agarwal