Re: Object Gateway - Server Side Encryption

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux