Ahti Seier via FreeIPA-users wrote:
First of all. FreeIPA servers should be one of the best guarded
servers
in any infrastructure. In addition to service private keys they contain
the private key to the internal CA certificate, the kerberos database
(user password hashes) etc. It is a very bad idea to run other
non-related services on these hosts.
As far as I understand, the services under "Services" are mostly
kerberos service principals. I haven't seen any standard list as to what
a service name can be. So basically you can configure
whateveryouwant/my-host. There are several standard service names (HTTP,
cifs, nfs etc.) and the respective clients to these services know to
query these. For example your web browser will go and make a request for
HTTP/my_host@MY_REALM service ticket when you navigate to
https://my_host and it has "Negotiate" authentication configured. This
allows you to authenticate to that web service based on your logon
credentials (kerberos ticket (no password)).
Right, I'm not aware of a complete list of Kerberos service principal
prefixes either beyond what is already in IPA. It's basically a
per-protocol/service naming that is not at all consistent.
A few suggestions:
1. If you aren't planning on using Kerberos for it, the service name
isn't too important, just make it descriptive for your purposes
2. If you do plan to use Kerberos for it you'll need to dig into the
documentation for that service to determine what the name should be. If
you *might* use kerberos/GSSAPI auth later I'd also dig into the proper
name.
A certificate needs to be associated with an object inside of IPA. The
name of the object needs to match the subject of the certificate, or be
allowed to manage that name. Think of it as a bucket. For a
non-kerberized service it's a holder of the cert.
rob
Kontakt lejeczek via FreeIPA-users
(<freeipa-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>>) kirjutas kuupäeval K, 9.
veebruar 2022 kell 09:43:
On 08/02/2022 19:33, Ahti Seier via FreeIPA-users wrote:
> Hello,
>
> I don't think there is one correct answer to this question. It
> depends on the services and how those hosts and services are managed.
>
> From a security perspective you need to have confidence that your
> private keys are secure and have not been been compromised. So if the
> services are administered by different teams or people it is
better to
> separate the keys and control access to them so that each team and
> service would have access only to their own keys. Meaning it is
better
> to have a certificate for each service. This will not save you if one
> of the keys gets compromised, but it is better to figure out how it
> happened and who is responsible if/when it does. It is a good idea if
> these certificates are with a different subject name because when one
> is expiring or there is some issue with it it is easier to understand
> which one it is. The OU field in the subject DN is a good way to
> separate these.
>
> If the server and all its services are managed by a single
> team/person and the impact of key compromise is not that severe then
> having one certificate for multiple services can be simpler to
manage.
> All services will have access to the same private key. This has the
> effect that when a key does get compromised you will have a hard time
> figuring out how or through which service it could have happened.
>
> Just my 2c,
> Ahti
>
okey, so another one obvious - how about masters themselves? (put the
recommendation that IPA boxes should be IPA exclusive aside for now)
I assume most of us if did not do then at least were tempted to have
databases (other than IPA's) on masters - if you do/did that would you
then use master's or separate/dedicated cert? (risks possibilities are
what they are but I'm still curious to hear opinions & thoughts)
and btw. Is there a defined list of - IPA's or greater standard -
approved/supported services or we create those at whim as we go? eg.
mysql/my-host posgresql/my-host .etc
many thanks, L.
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
<mailto:freeipa-users@lists.fedorahosted.org>
To unsubscribe send an email to
freeipa-users-leave(a)lists.fedorahosted.org
<mailto:freeipa-users-leave@lists.fedorahosted.org>
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
_______________________________________________
FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure