a4f634bd89
The keystoneauth middleware supports cross-tenant access control using the syntax <tenant>:<user> in container ACLs, where <tenant> and <user> may currently be either a unique id or a name. As a result of the keystone v3 API introducing domains, names are no longer globally unique and are only unique within a domain. The use of unqualified tenant and user names in this ACL syntax is therefore not 'safe' in a keystone v3 environment. This patch modifies keystoneauth to restrict cross-tenant ACL matching to use only ids for accounts that are not in the default domain. For backwards compatibility, names will still be matched in ACLs when both the requesting user and tenant are known to be in the default domain AND the account's tenant is also in the default domain (the default domain being the domain to which existing tenants are migrated). Accounts existing prior to this patch are assumed to be for tenants in the default domain. New accounts created using a v2 token scoped on the tenant are also assumed to be in the default domain. New accounts created using a v3 token scoped on the tenant will learn their domain membership from the token info. New accounts created using any unscoped token, (i.e. with a reselleradmin role) will have unknown domain membership and therefore be assumed to NOT be in the default domain. Despite this provision for backwards compatibility, names must no longer be used when setting new ACLs in any account, including new accounts in the default domain. This change obviously impacts users accustomed to specifying cross-tenant ACLs in terms of names, and further work will be necessary to restore those use cases. Some ideas are discussed under the bug report. With that caveat, this patch removes the reported vulnerability when using swift/keystoneauth with a keystone v3 API. Note: to observe the new 'restricted' behaviour you will need to setup keystone user(s) and tenant(s) in a non-default domain and set auth_version = v3.0 in the auth_token middleware config section of proxy-server.conf. You may also benefit from the keystone v3 enabled swiftclient patch under review here: https://review.openstack.org/#/c/91788/ DocImpact blueprint keystone-v3-support Closes-Bug: #1299146 Change-Id: Ib32df093f7450f704127da77ff06b595f57615cb
80 lines
2.3 KiB
Plaintext
80 lines
2.3 KiB
Plaintext
[func_test]
|
|
# sample config for Swift with tempauth
|
|
auth_host = 127.0.0.1
|
|
auth_port = 8080
|
|
auth_ssl = no
|
|
auth_prefix = /auth/
|
|
## sample config for Swift with Keystone v2 API
|
|
# For keystone v3 change auth_version to 3 and auth_prefix to /v3/
|
|
#auth_version = 2
|
|
#auth_host = localhost
|
|
#auth_port = 5000
|
|
#auth_ssl = no
|
|
#auth_prefix = /v2.0/
|
|
|
|
# Primary functional test account (needs admin access to the account)
|
|
account = test
|
|
username = tester
|
|
password = testing
|
|
|
|
# User on a second account (needs admin access to the account)
|
|
account2 = test2
|
|
username2 = tester2
|
|
password2 = testing2
|
|
|
|
# User on same account as first, but without admin access
|
|
username3 = tester3
|
|
password3 = testing3
|
|
|
|
# Fourth user is required for keystone v3 specific tests.
|
|
# Account must be in a non-default domain.
|
|
#account4 = test4
|
|
#username4 = tester4
|
|
#password4 = testing4
|
|
#domain4 = test-domain
|
|
|
|
collate = C
|
|
|
|
# Only necessary if a pre-exising server uses self-signed certificate
|
|
insecure = no
|
|
|
|
[unit_test]
|
|
fake_syslog = False
|
|
|
|
[probe_test]
|
|
# check_server_timeout = 30
|
|
# validate_rsync = false
|
|
|
|
[swift-constraints]
|
|
# The functional test runner will try to use the constraint values provided in
|
|
# the swift-constraints section of test.conf.
|
|
#
|
|
# If a constraint value does not exist in that section, or because the
|
|
# swift-constraints section does not exist, the constraints values found in
|
|
# the /info API call (if successful) will be used.
|
|
#
|
|
# If a constraint value cannot be found in the /info results, either because
|
|
# the /info API call failed, or a value is not present, the constraint value
|
|
# used will fall back to those loaded by the constraints module at time of
|
|
# import (which will attempt to load /etc/swift/swift.conf, see the
|
|
# swift.common.constraints module for more information).
|
|
#
|
|
# Note that the cluster must have "sane" values for the test suite to pass
|
|
# (for some definition of sane).
|
|
#
|
|
#max_file_size = 5368709122
|
|
#max_meta_name_length = 128
|
|
#max_meta_value_length = 256
|
|
#max_meta_count = 90
|
|
#max_meta_overall_size = 4096
|
|
#max_header_size = 8192
|
|
#max_object_name_length = 1024
|
|
#container_listing_limit = 10000
|
|
#account_listing_limit = 10000
|
|
#max_account_name_length = 256
|
|
#max_container_name_length = 256
|
|
|
|
# Newer swift versions default to strict cors mode, but older ones were the
|
|
# opposite.
|
|
#strict_cors_mode = true
|