Hi Casey Thank you for your help. We fixed the problem on the same day but then I forgot to post back the solution here... So basically we had 2 problems: -the barbican secret key payload need to be exactly 32 Bytes -the ceph.conf need a user id (username not ok): rgw keystone barbican user = <rgwcrypt_uid> And of course this rgwuser need the read permissions on the barbican secret. Best Regards Francois ________________________________________ From: ceph-users <ceph-users-bounces@xxxxxxxxxxxxxx> on behalf of Casey Bodley <cbodley@xxxxxxxxxx> Sent: Thursday, April 25, 2019 7:21 PM To: ceph-users@xxxxxxxxxxxxxx Subject: Re: Object Gateway - Server Side Encryption On 4/25/19 11:33 AM, Francois Scheurer wrote: > Hello Amardeep > We are trying the same as you on luminous. > s3cmd --access_key xxx --secret_key xxx --host-bucket '%(bucket)s.s3.xxx.ch' --host s3.xxx.ch --signature-v2 --no-preserve --server-side-encryption \ > --server-side-encryption-kms-idhttps://barbican.service.xxx.ch/v1/secrets/ffa60094-f88b-41a4-b63f-c07a017ad2b5 put hello.txt3 s3://test/hello.txt3 > > upload: 'hello.txt3' -> 's3://test/hello.txt3' [1 of 1] > 13 of 13 100% in 0s 14.25 B/s done > ERROR: S3 error: 400 (InvalidArgument): Failed to retrieve the actual key, kms-keyid:https://barbican.service.xxx.ch/v1/secrets/ffa60094-f88b-41a4-b63f-c07a017ad2b5 > openstack --os-cloud fsc-ac secret gethttps://barbican.service.xxx.ch/v1/secrets/ffa60094-f88b-41a4-b63f-c07a017ad2b5 > +---------------+----------------------------------------------------------------------------------+ > | Field | Value | > +---------------+----------------------------------------------------------------------------------+ > | Secret href |https://barbican.service.xxx.ch/v1/secrets/ffa60094-f88b-41a4-b63f-c07a017ad2b5 | > | Name | fsc-key3 | > | Created | 2019-04-25T14:31:52+00:00 | > | Status | ACTIVE | > | Content types | {u'default': u'application/octet-stream'} | > | Algorithm | aes | > | Bit length | 256 | > | Secret type | opaque | > | Mode | cbc | > | Expiration | 2020-01-01T00:00:00+00:00 | > +---------------+----------------------------------------------------------------------------------+ > We also tried using --server-side-encryption-kms-id ffa60094-f88b-41a4-b63f-c07a017ad2b5 > or --server-side-encryption-kms-id fsc-key3 with the same error. > > > vim /etc/ceph/ceph.conf > rgw barbican url =https://barbican.service.xxx.ch > rgw keystone barbican user = rgwcrypt > rgw keystone barbican password = xxx > rgw keystone barbican project = service > rgw keystone barbican domain = default > rgw crypt require ssl = false > Thank you in advance for your help. > > > > Best Regards > Francois Scheurer > > _______________________________________________ > ceph-users mailing list > ceph-users@xxxxxxxxxxxxxx > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com I think rgw is expecting these keyids to look like "ffa60094-f88b-41a4-b63f-c07a017ad2b5", so it doesn't url-encode them when sending the request to barbican. In this case, the keyid is itself a url, so rgw is sending a request to "https://barbican.service.xxx.ch/v1/secrets/https://barbican.service.xxx.ch/v1/secrets/ffa60094-f88b-41a4-b63f-c07a017ad2b5";. It's hard to tell without logs from barbican, but I suspect that it's trying to interpret the slashes as part of the request path, rather than part of the keyid. So I would recommend using keyids of the form "ffa60094-f88b-41a4-b63f-c07a017ad2b5", but would also consider the lack of url-encoding to be a bug. I opened a ticket for this at http://tracker.ceph.com/issues/39488 - feel free to add more information there. Barbican log output showing the request/response would be helpful! Casey _______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ ceph-users mailing list ceph-users@xxxxxxxxxxxxxx http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
