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-boun...@lists.ceph.com> on behalf of Casey Bodley 
<cbod...@redhat.com>
Sent: Thursday, April 25, 2019 7:21 PM
To: ceph-users@lists.ceph.com
Subject: Re: [ceph-users] 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@lists.ceph.com
> 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@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
ceph-users mailing list
ceph-users@lists.ceph.com
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com

Reply via email to