The publishing credentials for this job are misconfigured in Zuul and
result in the whole post pipeline failing, which causes tarballs not to
be updated on tarballs.openstack.org[1]. Remove the misconfigured job to
get the post pipeline working again.
[1] http://eavesdrop.openstack.org/irclogs/%23openstack-release/%23openstack-release.2019-03-11
Change-Id: I4d94a433ba32bce7ee926cdde487eeec980c6b8b
If the new primary key is not the first to be distributed after fernet
key rotation, there may be a small time window during the key
distribution when tokens issued by the node where fernet rotation was
performed can not be validated on the node where keys are being
distributed to.
Change-Id: I34b5cadd12815ee95c71d8c163504390a9e5e343
Closes-Bug: #1816927
By incorporating system-scope and default roles, we've effectively
made these policies obsolete. We can simplify what we maintain and
provide a more consistent, unified view of default service behavior by
removing them.
Change-Id: Ifa2282481ee3fc544c1d50ac8e8972b0d3a5332e
Closes-Bug: 1804462
Ubuntu Xenial is nearing its end of life, so it's not ideal to keep
testing on it and the QA team is driving an effort to move everyone away
from it[1]. However, our non-voting federation jobs rely on the
Shibboleth service provider Apache module, which does not work on Ubuntu
Bionic[2]. Since the keystone devstack plugin now has support for CentOS
and openSUSE, let's transition away from Ubuntu for this testing.
The reason to choose openSUSE rather then CentOS is that the Shibboleth
service provider package for CentOS relies on an external repository and
is not included in either the base CentOS distro or EPEL. The
shibboleth-sp package for openSUSE is included in the base distro
packages.
[1] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003129.html
[2] https://bugs.launchpad.net/ubuntu/+source/shibboleth-sp2/+bug/1776489
Change-Id: I89a8af9c45ff513c854c048880854990a6d12278
In the case that operators want to allow users to have unrestricted
ability to create access rules for application credentials, add a config
option to allow them to not have to create access rules config files.
bp whitelist-extension-for-app-creds
Change-Id: I10939b83cd6e72f0205f0191c7df9bca2cef8483
Expose the access rules config driver as a manager. The unit tests are
light because the main functionality is tested for the driver directly.
bp whitelist-extension-for-app-creds
Change-Id: I8988dadfe5f82d9b9d6563246b692add8ea4f22f
The access rules config driver will read a JSON file that represents
rules for accessing service APIs. This is to support application
credential access rules, which will be checked against the configured
rules upon creation. The name for this new API is borrowed from Istio's
near identical concept[1].
[1] https://istio.io/docs/reference/config/authorization/istio.rbac.v1alpha1/#AccessRule
bp whitelist-extension-for-app-creds
Change-Id: If8b9c1e9df55874052dfd9b99fbcea6e06c1ca35
By incorporating system-scope and default roles, we've effectively
made these policies obsolete. We can simplify what we maintain and
provide a more consistent, unified view of default protocol
behavior by removing them.
Related-Bug: 1806762
Closes-Bug: 1804518
Change-Id: Ia839555d8211596213311c4246135cdae4f46ab2
This commit introduces some tests that show how project users
are expected to behave with the services API. A subsequent patch
will clean up the new obsolete policies in the
policy.v3cloudsample.json file.
Change-Id: Ib05e5bf96c992aa498d3812aea5e80dbe1a56377
Related-Bug: 1804462
By incorporating system-scope and default roles, we've effectively
made these policies obsolete. We can simplify what we maintain and
provide a more consistent, unified view of default role behavior by
removing them.
Note that these changes are slightly different from the
policy.v3cloudsample.json role policies, hence the removed tests. In
policy.v3cloudsample.json, domain users were allowed to get and list
global roles. So were project users. This behavior is changing because
global roles are considered global resources of the deployment, and
they should be managed by system users. Domain users should be able to
add and remove domain specific roles, which will come in a subsequent
series of patches. This approach is being taken because it is a safer
default for a system level resource (global roles) and still allows
the same functionality for domain users through domain-specific roles.
Change-Id: Iddaa59024a1dcefd4d791b95413602865888c1ff
Closes-Bug: 1806713
This commit introduces test coverage that explicitly shows how
project users are expected to behave global role resources. A
subsequent patch will clean up the now obsolete policies in the
policy.v3cloudsample.json policy file.
Change-Id: Id0dc3022ab294e73aeaa87e130bea4809f8c982b
Partial-Bug: 1806713
This commit adds explicit tests that show how domain users
are expected to behave with global roles. A subsequent patch
will do the same for project users.
Note that these changes are slightly different from the
policy.v3cloudsample.json role policies. In policy.v3cloudsample.json,
domain users were allowed to get and list global roles. So were
project users. This behavior is changing because global roles are
considered global resources of the deployment, and they should be
managed by system users. Domain users should be able to add and remove
domain specific roles, which will come in a subsequent series of
patches. This approach is being taken because it is a safer default
for a system level resource (roles) and still allows the same
functionality for domain users through domain-specific roles.
Change-Id: Ia1a7adf4431042ecea1b41e3c589c55112183ab5
Partial-Bug: 1806713
Partial-Bug: 1805400