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 > (<[email protected] > <mailto:[email protected]>>) 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 -- [email protected] > <mailto:[email protected]> > To unsubscribe send an email to > [email protected] > <mailto:[email protected]> > 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/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > > > _______________________________________________ > FreeIPA-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected] > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
