[kolla-ansible] External Ceph keyring encryption
Hi all, My understanding is that KA has dropped support for provisioning Ceph directly, and now requires an external Ceph cluster (side note: we should update the docs[1], which state it is only "sometimes necessary" to use an external cluster--I will try to submit something today). I think this works well, but the handling of keyrings cuts a bit against the grain of KA. The keyring files must be dropped in to the node_custom_config directory. This means that operators who prefer to keep their KA configuration in source control must have some mechanism for securing that, as it is unencrypted. What does everybody think about storing Ceph keyring secrets in passwords.yml instead, similar to how SSH keys are handled? Thanks, /Jason [1]: https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-c... -- Jason Anderson Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory
Hi Jason, I don’t think it should be instead, we could support both modes - happy to help in reviewing/co-authoring. Best regards, Michal On Wed, 19 Feb 2020 at 18:23, Jason Anderson <jasonanderson@uchicago.edu> wrote:
Hi all,
My understanding is that KA has dropped support for provisioning Ceph directly, and now requires an external Ceph cluster (side note: we should update the docs[1], which state it is only "sometimes necessary" to use an external cluster--I will try to submit something today).
I think this works well, but the handling of keyrings cuts a bit against the grain of KA. The keyring files must be dropped in to the node_custom_config directory. This means that operators who prefer to keep their KA configuration in source control must have some mechanism for securing that, as it is unencrypted. What does everybody think about storing Ceph keyring secrets in passwords.yml instead, similar to how SSH keys are handled?
Thanks, /Jason
[1]: https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-c...
-- Jason Anderson
Chameleon DevOps Lead *Consortium for Advanced Science and Engineering, The University of Chicago* *Mathematics & Computer Science Division, Argonne National Laboratory*
-- Michał Nasiadka mnasiadka@gmail.com
Hi Jason, Ansible autodecrypts files on copy so they can be stored encrypted. It could go in docs. :-) -yoctozepto śr., 19 lut 2020 o 18:36 Michał Nasiadka <mnasiadka@gmail.com> napisał(a):
Hi Jason,
I don’t think it should be instead, we could support both modes - happy to help in reviewing/co-authoring.
Best regards, Michal
On Wed, 19 Feb 2020 at 18:23, Jason Anderson <jasonanderson@uchicago.edu> wrote:
Hi all,
My understanding is that KA has dropped support for provisioning Ceph directly, and now requires an external Ceph cluster (side note: we should update the docs[1], which state it is only "sometimes necessary" to use an external cluster--I will try to submit something today).
I think this works well, but the handling of keyrings cuts a bit against the grain of KA. The keyring files must be dropped in to the node_custom_config directory. This means that operators who prefer to keep their KA configuration in source control must have some mechanism for securing that, as it is unencrypted. What does everybody think about storing Ceph keyring secrets in passwords.yml instead, similar to how SSH keys are handled?
Thanks, /Jason
[1]: https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-c...
-- Jason Anderson
Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory
-- Michał Nasiadka mnasiadka@gmail.com
Oh wow, I did not know it could do this transparently. Thanks, I will have a look at that. I can update the docs to reference this approach as well if it works out. Cheers! /Jason On 2/19/20 11:46 AM, Radosław Piliszek wrote:
Hi Jason,
Ansible autodecrypts files on copy so they can be stored encrypted. It could go in docs. :-)
-yoctozepto
śr., 19 lut 2020 o 18:36 Michał Nasiadka <mnasiadka@gmail.com> napisał(a):
Hi Jason,
I don’t think it should be instead, we could support both modes - happy to help in reviewing/co-authoring.
Best regards, Michal
On Wed, 19 Feb 2020 at 18:23, Jason Anderson <jasonanderson@uchicago.edu> wrote:
Hi all,
My understanding is that KA has dropped support for provisioning Ceph directly, and now requires an external Ceph cluster (side note: we should update the docs[1], which state it is only "sometimes necessary" to use an external cluster--I will try to submit something today).
I think this works well, but the handling of keyrings cuts a bit against the grain of KA. The keyring files must be dropped in to the node_custom_config directory. This means that operators who prefer to keep their KA configuration in source control must have some mechanism for securing that, as it is unencrypted. What does everybody think about storing Ceph keyring secrets in passwords.yml instead, similar to how SSH keys are handled?
Thanks, /Jason
[1]: https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-c...
-- Jason Anderson
Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory -- Michał Nasiadka mnasiadka@gmail.com
I just realized we also do a lookup on them and not sure if that works though. -yoctozepto śr., 19 lut 2020 o 18:52 Jason Anderson <jasonanderson@uchicago.edu> napisał(a):
Oh wow, I did not know it could do this transparently. Thanks, I will have a look at that. I can update the docs to reference this approach as well if it works out.
Cheers! /Jason
On 2/19/20 11:46 AM, Radosław Piliszek wrote:
Hi Jason,
Ansible autodecrypts files on copy so they can be stored encrypted. It could go in docs. :-)
-yoctozepto
śr., 19 lut 2020 o 18:36 Michał Nasiadka <mnasiadka@gmail.com> napisał(a):
Hi Jason,
I don’t think it should be instead, we could support both modes - happy to help in reviewing/co-authoring.
Best regards, Michal
On Wed, 19 Feb 2020 at 18:23, Jason Anderson <jasonanderson@uchicago.edu> wrote:
Hi all,
My understanding is that KA has dropped support for provisioning Ceph directly, and now requires an external Ceph cluster (side note: we should update the docs[1], which state it is only "sometimes necessary" to use an external cluster--I will try to submit something today).
I think this works well, but the handling of keyrings cuts a bit against the grain of KA. The keyring files must be dropped in to the node_custom_config directory. This means that operators who prefer to keep their KA configuration in source control must have some mechanism for securing that, as it is unencrypted. What does everybody think about storing Ceph keyring secrets in passwords.yml instead, similar to how SSH keys are handled?
Thanks, /Jason
[1]: https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-c...
-- Jason Anderson
Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory -- Michał Nasiadka mnasiadka@gmail.com
We had the exact same problem with an external ceph cluster and keyrings in source control. I can confirm that it works fine. The lookup was introduced on purpose in order to make vault encrypted keyrings possible ([1]). [1]: https://review.opendev.org/#/c/689753/ On Wed, 2020-02-19 at 19:02 +0100, Radosław Piliszek wrote:
I just realized we also do a lookup on them and not sure if that works though.
-yoctozepto
śr., 19 lut 2020 o 18:52 Jason Anderson <jasonanderson@uchicago.edu> napisał(a):
Oh wow, I did not know it could do this transparently. Thanks, I will have a look at that. I can update the docs to reference this approach as well if it works out.
Cheers! /Jason
On 2/19/20 11:46 AM, Radosław Piliszek wrote:
Hi Jason,
Ansible autodecrypts files on copy so they can be stored encrypted. It could go in docs. :-)
-yoctozepto
śr., 19 lut 2020 o 18:36 Michał Nasiadka <mnasiadka@gmail.com> napisał(a):
Hi Jason,
I don’t think it should be instead, we could support both modes - happy to help in reviewing/co-authoring.
Best regards, Michal
On Wed, 19 Feb 2020 at 18:23, Jason Anderson <jasonanderson@uchicago.edu> wrote:
Hi all,
My understanding is that KA has dropped support for provisioning Ceph directly, and now requires an external Ceph cluster (side note: we should update the docs[1], which state it is only "sometimes necessary" to use an external cluster--I will try to submit something today).
I think this works well, but the handling of keyrings cuts a bit against the grain of KA. The keyring files must be dropped in to the node_custom_config directory. This means that operators who prefer to keep their KA configuration in source control must have some mechanism for securing that, as it is unencrypted. What does everybody think about storing Ceph keyring secrets in passwords.yml instead, similar to how SSH keys are handled?
Thanks, /Jason
[1]: https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-c...
-- Jason Anderson
Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory -- Michał Nasiadka mnasiadka@gmail.com -- Jan Horstmann Systementwickler | Infrastruktur
Mittwald CM Service GmbH & Co. KG Königsberger Straße 4-6 32339 Espelkamp Tel.: 05772 / 293-900 Fax: 05772 / 293-333 j.horstmann@mittwald.de https://www.mittwald.de Geschäftsführer: Robert Meyer, Florian Jürgens St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar.
Ah, yeah. I had this gut feeling I tested that and I was right (but forgetful). -yoctozepto czw., 20 lut 2020 o 09:50 Jan Horstmann <J.Horstmann@mittwald.de> napisał(a):
We had the exact same problem with an external ceph cluster and keyrings in source control. I can confirm that it works fine. The lookup was introduced on purpose in order to make vault encrypted keyrings possible ([1]).
[1]: https://review.opendev.org/#/c/689753/
On Wed, 2020-02-19 at 19:02 +0100, Radosław Piliszek wrote:
I just realized we also do a lookup on them and not sure if that works though.
-yoctozepto
śr., 19 lut 2020 o 18:52 Jason Anderson <jasonanderson@uchicago.edu> napisał(a):
Oh wow, I did not know it could do this transparently. Thanks, I will have a look at that. I can update the docs to reference this approach as well if it works out.
Cheers! /Jason
On 2/19/20 11:46 AM, Radosław Piliszek wrote:
Hi Jason,
Ansible autodecrypts files on copy so they can be stored encrypted. It could go in docs. :-)
-yoctozepto
śr., 19 lut 2020 o 18:36 Michał Nasiadka <mnasiadka@gmail.com> napisał(a):
Hi Jason,
I don’t think it should be instead, we could support both modes - happy to help in reviewing/co-authoring.
Best regards, Michal
On Wed, 19 Feb 2020 at 18:23, Jason Anderson <jasonanderson@uchicago.edu> wrote:
Hi all,
My understanding is that KA has dropped support for provisioning Ceph directly, and now requires an external Ceph cluster (side note: we should update the docs[1], which state it is only "sometimes necessary" to use an external cluster--I will try to submit something today).
I think this works well, but the handling of keyrings cuts a bit against the grain of KA. The keyring files must be dropped in to the node_custom_config directory. This means that operators who prefer to keep their KA configuration in source control must have some mechanism for securing that, as it is unencrypted. What does everybody think about storing Ceph keyring secrets in passwords.yml instead, similar to how SSH keys are handled?
Thanks, /Jason
[1]: https://docs.openstack.org/kolla-ansible/latest/reference/storage/external-c...
-- Jason Anderson
Chameleon DevOps Lead Consortium for Advanced Science and Engineering, The University of Chicago Mathematics & Computer Science Division, Argonne National Laboratory -- Michał Nasiadka mnasiadka@gmail.com -- Jan Horstmann Systementwickler | Infrastruktur
Mittwald CM Service GmbH & Co. KG Königsberger Straße 4-6 32339 Espelkamp
Tel.: 05772 / 293-900 Fax: 05772 / 293-333
j.horstmann@mittwald.de https://www.mittwald.de
Geschäftsführer: Robert Meyer, Florian Jürgens
St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar.
participants (4)
-
Jan Horstmann
-
Jason Anderson
-
Michał Nasiadka
-
Radosław Piliszek