Berbican has been historically using own implementation with sqlalchemy
to connect to database but this causes some feature gaps with the other
services using oslo.db to generate database engine.
This replaces the own implementation by oslo.db's one so that barbican
can also leverage the features implemented in the shared library.
With this change the deprecated database options are removed, because
the deprecated options were already removed from oslo.db.
Change-Id: I10fe4ab04996885e8aff7fab8ace78a6fe7eb6e7
Since we removed certificate order, we no longer have to maintain
these logics.
This also removes the release note for deprecation of symantec
certificate plugin, which was added during this cycle, because
the plugin is also being removed by this change.
Change-Id: I8e901024677e889d05ad8653389fb46487bc7745
Currently Barbican is not using the periodic_task framework implemented
in oslo_service but implements its own mechanism based on the lower-
level thread group.
Change-Id: Idc69d61e07826923f3227aad6249252c3f739362
Barbican does not provide wsgi server based on oslo.service library,
thus these options are not used.
Change-Id: I74c67b61796bcc7e5418144b10134e6171b1777f
This ensures the options for oslo.versionedobjects library are
included in the file generated by oslo-config-generator.
Change-Id: I330b0bff32538bf22094257ecff5494af6d8e3d2
Depending on the paste configuration there
might be other log files in log directory
that needs to be rotated.
Also removes the comment that about the
debian directory that does not exist.
Change-Id: I90c50355f84e0e5c3b9fc1940ee6084c01bed97a
The default api-paste.ini file maintained in the Barbican repo provides
a pipeline with the audit middleware. This change adds the option for
the middleware to the barbican.conf file generated by generator, so
that users can find the related options easily.
Depends-on: https://review.opendev.org/804316
Change-Id: I9f3ee9968f7558498c6fdb31d9103750ec248446
The implementation follows nova and implements an is_supported
function, that can be used in controllers, to check the requested
version and take different code paths depending on the result.
This reverts commit 7b14d983e0dce6dcffe9781b05c52335b8203fc7.
Change-Id: I5651a69f93288ac1dfdc1c8b1ad0f904e370c127
The options used by service launchers in the oslo.service library were
missing from barbican.conf. This change ensures that these parameters
are picked up by oslo-config-generator.
Change-Id: Ib90fee2d09eec2d6e2755a7d56ec46c9c0154bcc
This change ensures the options of the healthcheck middleware, which is
enabled in api pipeline since [1] was merged, are included in
barbican.conf generated by the oslo-config-generator command.
[1] 3fc072d986f141b7153e4cd4543028f665f04ad0
Change-Id: I95418a2413591f326148fb1ab0954ada8941bfb1
The /healthcheck URL, as provided by oslo.middleware, is very
useful for operators to setup haproxy and to do monitoring.
Such feature is already in many services like Keystone, Glance,
and others. The same type of patch has just been approved in
Neutron.
Change-Id: Iad593e899ad2d236887c37a0c46d608817eaaf8f
Delete policy.json from repo since we can use policies registered
in code.
We can also change default policy rules through below steps:
- generate policy.yaml and copy to /etc/barbican
- configure `policy_file=policy.yaml` in `oslo_policy` section
- uncomment rules in policy.yaml and make changes as we desire
- restart barbican api service
- test whether new rules take effect on corresponding API
Change-Id: Ia64eac1eb4e30457b323c6ab99d26d3d40c28060
dogtag configurations have been moved to "plugin/dogtag_config_opts.py",
also remove non-existent entry point when generating barbican.conf
Closes-bug: #1704320
Change-Id: I9dd202d82797cb70051323fe949cc66f8a050022
This patch adds the basic framework for registering and using
default policy rules. Rules should be defined and returned from
a module in barbican/common/policies/, and then added to the
list in barbican/common/policies/__init__.py.
Also adds tox env to generate policy sample file.
Change-Id: If25b17ae7eed3f1a8e8e6f29701552a39d5a603f
A recent patch in devstack [1] forces the use of path access instead
of port for Keystone authentication, leading to connection error when
launching the devstack.
[1] https://review.openstack.org/#/c/456344/
Change-Id: I47b8035782bf27ee47227063381bc7dc041944b3
Currently etc/barbican/barbican.conf is maintained by hand and can not
be regenerated based on the config settings defined in the code.
A common pattern for OpenStack projects is to use oslo-config-generator
for that task.
Co-Authored-By: Randall Burt <randall.burt@rackspace.com>
Depends-On: I90870dcb49cd96f6bf0fe353fa6e779ffd87a5af
Closes-Bug: #1584789
Change-Id: I5f3dcd2fc982f1178ef7dd662c24d3166f91b266
Add missing kmip configuration to barbican.conf. Also, type of `port`
should be int, this will not cause error, but better following the API.
See [1]
[1] https://github.com/OpenKMIP/PyKMIP/blob/master/kmip/pie/client.py#L60
Change-Id: Ib16fbdda38016aab13683eae24aa6dcd1af5805a
Begins the deprecation process for Barbican CAs API,
and Barbican Certificate Orders Resource. This is
done through logging deprecation schedule on API,
as well as adding a warning to the documentation.
Change-Id: Idbe6307fa45527aa225e61b3b1ac9ca86e7660c5
Keystone auth configuration has been removed from barbican-api-paste.ini,
but not added to barbican.conf. This patch add these configurations.
Change-Id: I058a49ac60c3f1d72acd0f46379d9d05d1668a08
This sets up the HTTPProxyToWSGI middleware in front of Barbican.
The purpose of thise middleware is to set up the request URL
correctly in case there is a proxy (For instance, a loadbalancer
such as HAProxy) in front of Barbican.
The HTTPProxyToWSGI is off by default and needs to be enabled
via a configuration value.
Change-Id: Iad0151ca41684fa2d8eb60c343028e13c3719e66
Closes-bug: #1590608
This patch enables configuration of domains when using Keystone v3
authentication in the functional test suite.
Change-Id: If7fbb1924ebb99dc93eacedc371369fe1fa6312f
Added tests to provide 100% coverage on API and policy logic.
Change-Id: Icb43049250be1d78bdd3db8fbad0dc0381cccaf7
Partially-Implements: blueprint multiple-secret-backend
Added feature flag to enable/disable multiple backend support.
Added friendly plugin name in secretstore and crypto plugins conf.
Modified way of defining multiple plugin conf. With multiple backend
support, now plugins supported and global default plugin is defined
explictly in service configuration. With feature flag on, plugins
to be loaded are identified via reading new configuration structure.
Change-Id: I3c761c5a441f42c9f54a67d72514e8c1357a2e6a
Partially-Implements: blueprint multiple-secret-backend
I believe this is the correct behavior, as it would match how
containers handles these operations. This change facilitates
the LBaaS Barbican TLS workflow (which should be the same as
what other services will use in the future too).
The RBAC settings for consumer POST should be set to
use the same ACL rules as container GET (plus admin).
The RBAC settings for consumer DELETE should be:
* Any user with Delete permissions on the Container
* Any user that both: has ACL Read access to the Container; is a member
of the project that created the Consumer being deleted
Change-Id: Ie84784573893934c2887814a200e7386314b4f18
Closes-Bug: #1519170
Modified policy and tests to verify this change.
As per this change, user with 'creator' role can delete a secret or
a container as long as that user has initially created that secret
or container.
There is still a difference between 'admin' role and 'creator' role
behavior around delete operation. With this change, users with 'creator'
role cannot delete any other user's secret/container in same project
while user with 'admin' role can do that.
Updated role docs to reflect this behavior.
Change-Id: I53e5529ed34ac4acc76348ca0431cb3de7934b6d
This configures Barbican to use Keystone authentication by
default and updates documentation accordingly.
Change-Id: Ie0a1995b971371d18238138575629eeee1a36392
Closes-Bug: #1595428
Configuration with oslo.messaging is listed in the DEFAULT section
in etc/barbican/barbican.conf.
According to this Change "I96a9682afe7eb0caf1fbf47bbb0291833aec245b"
of oslo.messaging, we now prefer to set them in "oslo_messaging_rabbit"
section.
Closes-Bug: #1590231
Change-Id: I2b952012b2192cfb95e28cf11f78cf56d6a414ca
This adds POST and DELETE support for a 'secrets' sub-resource on the
containers resource. This will allow a user to add or remove secret
references to an existing container. Only generic containers are
supported per the blueprint for this feature.
If a secret reference already exists in the container, an appropriate
error will be returned indicating that the secret already exists in
the container. I chose this approach over silently accepting the
update, as the name for the container secret could change, so a delete
and re-add seems to be the safer option if a user just wants to change
the name, which is not something that I see happening too often.
Additionally, the action is a POST and not a PUT, so it shouldn't
really update an existing resource.
APIImpact
Add support for POST and DELETE on container secrets sub-resources
DocImpact
Implements: blueprint api-containers-add-put
Change-Id: I6dfa6715385f421e4f173cf73c2b75b68da67051
Auth_token middleware is expected to be configured by use of
oslo.config. Paste is really only mainted for swift. However paste
overrides the values provided in oslo.config so for anyone using
default barbican paste files and configuring auth_token middleware via
oslo.config they will have unexpected config overrides from the barbian
defaults.
Change-Id: I6bc49c4b62167410eaa70432f73abab2e829dc39
keystonemiddleware admin settings are deprecated
so we should stop using them in favor of a keystone
auth plugin. This patch updates the config file
to use keystone API v3 by default.
Change-Id: I9d10ac29ab33cbdd845573106960e5f181afdb69
Closes-Bug: 1579801
Currently barbican provides hostname part of hrefs returned in response
based on host_href value defined in barbican.conf.
This approach would not work if barbican API needs to be accessed via
public or internal endpoint as they can be different endpoints in
control planes. The endpoint used by client depends on which network client
is making the API request. For same reasons, keystone also allows different
endpoint for a service to expose as public or internal interface in service
catalog.
To allow that kind of deployment model for barbican service, now enhancing
its logic to derive this hostname (http_scheme+host+port) information from
wsgi requests when host_href value is not set in barbican.conf. So deployment
requiring this behavior can leave host_href blank in their barbican.conf. The
host_href needs to be set empty as not setting it results in default.
Generally in this kind of deployment, proxy (e.g. haproxy) will set
appropriate host, http scheme header. Request url received at barbican side
will have the client IP address and scheme inserted directly inside it.
Reference: https://en.wikipedia.org/wiki/X-Forwarded-For
Updated existing 'change host header' related functional test to skip when
host_href is not set in barbican server side. Added new functional tests when
hrefs are derived from wsgi request. New tests are skipped when host_href is
set at server side.
Added a flag in barbican-functional.conf to indicate barbican server setting
Default is to use CONF.host_href value. Explicit flag is added as functional
test setup may not always have barbican server conf available locally.
Change-Id: Idb8e62867f6cbd457eb64ea31500e93e74d247ea
Closes-Bug: 1541118
Normal requests from the functional tests specify verify=True to
validate certs. However, for internal or test deployments you
may require verify=False. This CR adds a line in
etc/barbican/barbican-functional.conf where you can configure
the setting for verify.
To set this, edit the etc/barbican/barbican-functional.conf
file and under the [keymanager] section, specify
verify_ssl=True (which is the default) or verify_ssl=False
to skip certificate validation.
Change-Id: Ie8eaa9348a938b9df31e9ff754bd2b5b78c26833
When debugging API calls, you often timeout because of breakpoints.
The default value is 10 seconds which isn't long enough for debugging.
This CR makes that setting configurable in barbican-functional.conf
and retains the default of 10 seconds.
Change-Id: I51685d5df903088773cba4ca624bbd0360ed0d16
The default values needed for barbican's implementation of cors
middleware have been moved from paste.ini into a common
set_middleware_defaults method, invoked on load.
Change-Id: I5722bfc31534936fd07a8dee4ca24afe81c06682
Closes-Bug: #1551836
The certificate event plugin specified in barbican.conf does not match
what is configured in setup.cfg. This CR fixes that issue.
Change-Id: I3a281f58622a376c189a2781f720456ab7a8162b
This patch adds the api functions for user metadata and tests for
those functions. It is the second of several patches which will
complete the "User Defined Metadata for Barbican Secrets" blueprint.
Other Patches will include:
1.) Documentation
Implements: blueprint add-user-metadata
Change-Id: Iaf83bf5a3b9ed2ea22d4cd3e83ba3a0d5d087adf
Barbican API Paste has a commented line which should not be there
and when using devstack the pipeline "barbican-api-keystone"
should be provided instead of individual components.
Change-Id: I517b651113ef1d3c0837f9ba85a70e6959fae764
Option "verbose" from group "DEFAULT" is deprecated from the oslo.log
library. Its value may be silently ignored in the future. If this option
is not set explicitly, there is no such warning.
Furthermore, the default value of verbose is true, so there is no
need to set this value in config files.
Change-Id: If760c42da26aefe49ae52415941e6146bcbccb6a
This change adds audit filter in paste ini file which can be used to add
this filter in existing request processing pipeline. Added new pipeline
with audit filter after keystone_authtoken filter.
Adding documentation about how to use this.
This change provides auditing on REST API side. Worker side changes will
be done later in another review and are not dependent on this.
Change-Id: I308796f5804aa55bc3d6496ded0504b469f00301
Partially-Implements: blueprint audit-cadf-events
