5:53 p.m.
Hi all,
until I do a further research how to achieve this: Can anybody tell me
if it's possible to handle multiple different PKI with different root ca
inside one debops project?
The situation: We admin multiple servers of different customers. Since
many of them are very similar we think about to manage them all in one
project in different host groups.
But the condition would be to have separate ca's.
Thanks and kind regards
Jan
8:24 p.m.
On Jan 17, Jan Kowalsky wrote:
until I do a further research how to achieve this: Can anybody tell
me
if it's possible to handle multiple different PKI with different root ca
inside one debops project?
The situation: We admin multiple servers of different customers. Since
many of them are very similar we think about to manage them all in one
project in different host groups.
But the condition would be to have separate ca's.
Yes, it is possible to manage multiple separate Certificate Authority chains
in one debops.pki setup.
When you look at the debops.pki defaults file,
https://github.com/debops/debops/blob/master/ansible/roles/debops.pki/def...,
you can see there variables:
- pki_authorities - this variable defines what CAs are managed by debops.pki,
the easiest way to extend it would be to copy it to the inventory and add
your own new list entries
- pki_authorities_ca_root - this variable defines the default 'Root CA'
authority, the important key being 'name' which defines the name you have to
refernce in intermediate authorities
- pki_authorities_ca_domain - this variable defines the default 'Domain CA'
intermediate authority. The 'issuer_name' defines the "parent CA"
which
signed this CA's certificate.
This defines a "chain" of Root CA + Domain CA, with Domain CA signing the
end-entity server certificates. In the 'pki_authorities' variable you can add
your own additional CAs, either as separate Root CAs, or as chains with
intermediate Authorities which might be preferable in the long run, in case
you have to revoke a CA for some reason.
But, I think that putting multiple separate clients in one DebOps environment
(project directory) might not be a good diea. The model of these directories
and the playbooks/roles are designed as self-contained entities. If you want
to use DebOps to manage multiple, separate clients, I would put each client
environment in its own separate DebOps project directory. That way passwords
for certain services like snmpd, shared databases, etc. are not exposed to
other clients. If you still want them to be able to talk with each other via
SSL with internal CAs, you can just cross-share the Root CA certificates
between the environments by putting them in 'secret/pki/ca-certificates/'
subdirectories.
Cheers,
Maciej Delmanowski
9:38 p.m.
Hi Maciej,
thanks for quick response.
Am 17.01.2019 um 20:24 schrieb Maciej Delmanowski:
On Jan 17, Jan Kowalsky wrote:
> until I do a further research how to achieve this: Can anybody tell me
> if it's possible to handle multiple different PKI with different root ca
> inside one debops project?
Yes, it is possible to manage multiple separate Certificate Authority
chains
in one debops.pki setup.
good to hear. I'll try to understand and test how it works
But, I think that putting multiple separate clients in one DebOps
environment
(project directory) might not be a good diea. The model of these directories
and the playbooks/roles are designed as self-contained entities. If you want
to use DebOps to manage multiple, separate clients, I would put each client
environment in its own separate DebOps project directory. That way passwords
for certain services like snmpd, shared databases, etc. are not exposed to
other clients. If you still want them to be able to talk with each other via
SSL with internal CAs, you can just cross-share the Root CA certificates
between the environments by putting them in 'secret/pki/ca-certificates/'
subdirectories.
Yes, generally we are aware, that it's not ideal to have different
clients in one project. The main issue isn't the pki. To share the root
ca could be interesting one day - e.g. when we need central logging over
tls.
But the consideration was, that we have a lot of group_vars for specific
purposes. E.g. common software lists for desktop clients, ciphers for
nginx or nextcloud configurations.
Until now we didn't find a good way to have every few hosts in it's own
project (sometimes they are only 2 to 5 hosts) but still share the
group_vars between them.
For example: we have some ltsp environments - every of them quite
similar configured: a host with very few vms: one for desktop another
for public cloud and maybe some other for sql and special applications.
If we find some issues in one installation it's pretty probable that we
want to fix this in all installations. E.g. we need newer packages, a
custom patch or maybe we want to change all admin ssh keys. In this case
it's much easier if they're all in one project and depend e.g. on one
group_all with admin-users defined or one group with all ltsp-servers
inside.
So if you have a good idea how to organize this, we would appreciate
this a lot. Maybe we could think about symlinking some parts of the
inventory to the particular projects ...
Thanks a lot and kind regards
Jan
9:15 a.m.
On Jan 18, Jan Kowalsky wrote:
For example: we have some ltsp environments - every of them quite
similar configured: a host with very few vms: one for desktop another
for public cloud and maybe some other for sql and special applications.
If we find some issues in one installation it's pretty probable that we
want to fix this in all installations. E.g. we need newer packages, a
custom patch or maybe we want to change all admin ssh keys. In this case
it's much easier if they're all in one project and depend e.g. on one
group_all with admin-users defined or one group with all ltsp-servers
inside.
So if you have a good idea how to organize this, we would appreciate
this a lot. Maybe we could think about symlinking some parts of the
inventory to the particular projects ...
Essentially yes, multiple project directories with parts of the inventory
symlinked between them would be a solution to this.
If you want to use inventory groups, you should consider defining the
'ansible_group_priority' variables to define the parent/child group
precedence. You can then define a set of high-level groups that define
variables, and low-level groups that group the hosts together.
https://docs.ansible.com/ansible/latest/user_guide/intro_inventory.html#h...
Good luck. :-)
Maciej Delmanowski
1915
days inactive
1920
days old
3 comments
2 participants
participants (2)
-
Jan Kowalsky -
Maciej Delmanowski