Bug 1683290 - Rados gateway container does not mount TLS directory
Summary: Rados gateway container does not mount TLS directory
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Ceph Storage
Classification: Red Hat Storage
Component: Ceph-Ansible
Version: 3.2
Hardware: All
OS: Unspecified
medium
medium
Target Milestone: z1
: 3.2
Assignee: Francesco Pantano
QA Contact: Vasishta
URL:
Whiteboard:
: 1683930 (view as bug list)
Depends On:
Blocks: 1578730
TreeView+ depends on / blocked
 
Reported: 2019-02-26 14:21 UTC by Gregory Charot
Modified: 2019-10-24 11:46 UTC (History)
16 users (show)

Fixed In Version: RHEL: ceph-ansible-3.2.8-1.el7cp Ubuntu: ceph-ansible_3.2.8-2redhat1
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-03-07 15:51:42 UTC
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github ceph ceph-ansible pull 3638 0 None closed ceph-radosgw bz#1683290 2020-07-31 00:22:51 UTC
Github ceph ceph-ansible pull 3648 0 None closed Automatic backport of pull request #3638 2020-07-31 00:22:51 UTC
Red Hat Product Errata RHBA-2019:0475 0 None None None 2019-03-07 15:51:50 UTC

Description Gregory Charot 2019-02-26 14:21:18 UTC
Description of problem:

When deploying OSP13 with TLS everywhere and RGW instead of swift, all swift commands fail.

Version-Release number of selected component (if applicable):

13

How reproducible:

Always

Steps to Reproduce:
1. Deploy OSP13 with TLS everywhere (w/ IDM) and RGW
2. openstack container list
3.

Actual results:

[stack@undercloud ~]$ source overcloudrc
(overcloud) [stack@undercloud ~]$ openstack container list
Unauthorized (HTTP 401) (Request-ID: tx0000000000000000018b9-005c7540b7-10b1-default)
(overcloud) [stack@undercloud ~]$ swift list
Account GET failed: https://overcloud.redhat.local:13808/swift/v1?format=json 401 Unauthorized  [first 60 chars of response] {"Code":"AccessDenied","RequestId":"tx0000000000000000018c5-
Failed Transaction ID: tx0000000000000000018c5-005c7540be-109a-default

Expected results:

Ability to perform object operations


Additional info:

The /etc/pki directory is not mounted into the container therefore the certificate cannot be verfied. 

RGW logs show:
2019-02-26 13:46:21.042100 7fd839cfe700  0 curl_easy_perform returned status 60 error: Peer's Certificate issuer is not recognized.
2019-02-26 13:46:21.042266 7fd839cfe700  1 ====== req done req=0x7fd839cf7f90 op status=0 http_status=401 ======
2019-02-26 13:46:21.042328 7fd839cfe700  1 civetweb: 0x55624e82e000: 172.17.3.202 - - [26/Feb/2019:13:46:21 +0000] "GET /swift/v1?format=json HTTP/1.1" 401 0 - osc-lib/1.9.0 keystoneauth1/3.4.0 python-requests/2.14.2 CPython/2.7.5

The following steps solve the issue, proper automation work is required to fix this.

On the system(s) hosting the RGW:

Add -v /etc/pki:/etc/pki:ro \
In /etc/systemd/system/ceph-radosgw\@.service

systemctl daemon-reload
systemctl restart ceph-radosgw.service

Comment 2 Gregory Charot 2019-02-26 16:41:11 UTC
For security reasons you may not want to bind the entire /etc/pki directory

Comment 3 Dimitri Savineau 2019-02-26 16:46:42 UTC
Could you specify the ceph-ansible version used ? (3.2 I suppose)

While adding the /etc/pki directory seems to resolves the issue we might be more specific on the file/dir path like other OpenStack containers (because we only need the CA)

https://github.com/openstack/tripleo-heat-templates/blob/stable/queens/docker/services/containers-common.yaml#L94-L98

Comment 4 Gregory Charot 2019-02-26 16:50:16 UTC
 rpm -qa | grep ceph-an
ceph-ansible-3.2.7-1.el7cp.noarch

As for /etc/pki yes agreed, I did mount the entire directory just to find to root cause and as mentioned in my previous comment we should only mount what is actually needed.

Comment 7 Sébastien Han 2019-02-28 09:10:30 UTC
*** Bug 1683930 has been marked as a duplicate of this bug. ***

Comment 16 errata-xmlrpc 2019-03-07 15:51:42 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2019:0475


Note You need to log in before you can comment on or make changes to this bug.