Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

As a CentOS Sysadmin, I want to be able to generate node x509 certs without having to enroll them into IPA, due to security concerns (we just need x509 cert, nothing else). #33

Open
sfinn85 opened this issue Dec 23, 2019 · 24 comments
Labels
Projects

Comments

@sfinn85
Copy link

@sfinn85 sfinn85 commented Dec 23, 2019

No description provided.

@puiterwijk

This comment has been minimized.

Copy link
Member

@puiterwijk puiterwijk commented Jan 6, 2020

What security concerns would you see by creating the node in IPA?
By default they get nothing, unless you grant them specific credentials to access things.

@puiterwijk puiterwijk transferred this issue from fedora-infra/freeipa-fas Jan 6, 2020
@arrfab

This comment has been minimized.

Copy link

@arrfab arrfab commented Jan 10, 2020

It would be good to get notifications about this git repo, and not discovering it by accident .. and so participating in the thread, and hopefully get notifications

It was agreed that CentOS nodes will not be in IPA, so no :)

@relrod

This comment has been minimized.

Copy link
Member

@relrod relrod commented Jan 20, 2020

@arrfab you can 'watch' the repo and get notifications. @puiterwijk probably knows more about the x509 requirements here than I do, so any insight is appreciated.

@abompard abompard added this to In progress in AAA Jan 24, 2020
@abompard abompard moved this from In progress to To do in AAA Jan 24, 2020
@sfinn85 sfinn85 moved this from To do to Backlog in AAA Feb 4, 2020
@sfinn85

This comment has been minimized.

Copy link
Author

@sfinn85 sfinn85 commented Feb 5, 2020

@abompard do we need more insight on this for sprint planning tomorrow?

@abompard

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 5, 2020

Yeah, @relrod's comment still stands. @arrfab , @puiterwijk , any idea?

@puiterwijk

This comment has been minimized.

Copy link
Member

@puiterwijk puiterwijk commented Feb 5, 2020

@abompard @relrod So, after discussing with @arrfab, we came to the conclusion that their problems are with ipa-client.
You can actually register the system (and make it available for x509 certs and everything) without installing ipa-client on the system, which would alleviate their problems. So I think this ticket can be closed.

@arrfab

This comment has been minimized.

Copy link

@arrfab arrfab commented Feb 5, 2020

We need a way to have the x509 certs generated through dogtag/IPA, and retrieved, so that ansible can (re)configure our nodes, including koji builders.
Failure to have such feature rolled-in would be considered a blocker for CentOS Stream, as builders are using that intensively :-)

@arrfab

This comment has been minimized.

Copy link

@arrfab arrfab commented Feb 5, 2020

@puiterwijk is also right (as always) : we can't have the CentOS nodes enrolled directly into IPA, and so no "ipa-client" on our nodes for now, so we'll just (as we do for existing FAS), consider IPA a "user/group DB" that will be used to grant access through openid/openidc for various services. But nodes RBAC will be managed by ansible

@relrod

This comment has been minimized.

Copy link
Member

@relrod relrod commented Feb 5, 2020

@abompard so the work here is figuring out, assuming that a node is "enrolled" (without having IPA client on it) how to call the IPA certificate generation API endpoint in the right way to generate the kinds of certs they need. This is something we'll likely need to work closely on with @arrfab and @puiterwijk both, because they know more about both: the requirements there and how PKI works, than probably anybody on the current AAA team including myself.

@sfinn85

This comment has been minimized.

Copy link
Author

@sfinn85 sfinn85 commented Feb 6, 2020

Sprint planning 3 update:

Insight needed from CentOS Team to move this forward and will need some help from CentOS team.
Not pulled into Sprint 3 for now, we may include it mid sprint if we have the capacity.

@abompard abompard moved this from Backlog to To do in AAA Feb 6, 2020
@abompard abompard moved this from To do to Backlog in AAA Feb 6, 2020
@sfinn85

This comment has been minimized.

Copy link
Author

@sfinn85 sfinn85 commented Feb 6, 2020

Adding notes from email from Fabian 2/6/20

Our koji builders (including for CentOS Stream, but not only those) need
TLS auth and so we need to :

  • generate nodes certificates from IPA/Dogtag
  • have users generate those as they do with FAS (so calling the
    /dogencert URL for fas)
  • have IPA/Security regenerate automatically.CRL when users are
    disabled or when the previous cert was revoked (we load those to ensure that
    someone disabled isn't able to touch service anymore)
@sfinn85

This comment has been minimized.

Copy link
Author

@sfinn85 sfinn85 commented Feb 6, 2020

Fabian and Aurélien possibly catching up on this tomorrow

@abompard

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 7, 2020

As I understand it at the moment, Securitas has to provide a new endpoint that :

  • will allow upload of a Certificate Signing Request
  • will call the IPA cert-request endpoint with this CSR and return the corresponding signed certificate back to the caller
  • is open to any authenticated user (and would use that user's session to do the API call).

Here are a few things that I'm not sure of:

  • according to the IPA docs, kerberos principals must be created before we request a signed cert. Do we want to or need to?
  • does this sound sane from a security point of view?

I'd love to have opinions on this process from people who know how things should be done with FreeIPA (@tiran , @puiterwijk ?). Thanks!

@arrfab

This comment has been minimized.

Copy link

@arrfab arrfab commented Feb 7, 2020

Well, Securitas would require the user to be authenticated to send the CSR, but it would reuse his token to then call the IPA endpoint to sign CSR with the CA from dogtag/IPA.
But any authenticated/validated user can request a cert to be signed by IPA, that's what I meant :)

@abompard

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 7, 2020

Thanks, I'll correct my comment.

@tiran

This comment has been minimized.

Copy link

@tiran tiran commented Feb 10, 2020

What kind of certificate do you want to generate? IPA enforces additional restrictions. A user can only request certificates for her/his own user name. A host or service can only request server certificates for their own host name/IP address. Additionally it is possible to delegate management (ipa host-add-managedby).

I recommend that you enroll the host and create services for CentOS machines, too. This will not only create all necessary entries in IPA. You also get additional features like automated cert request and renewal with certmonger.

@arrfab

This comment has been minimized.

Copy link

@arrfab arrfab commented Feb 10, 2020

@tiran we need nodes/users certificates mainly for Koji, and that was part of the requirements list when AAA started. If there is a way to enroll virtually nodes in IPA without having those really part of IPA network (so no ipa* pkg installled on those nodes), and that an admin can request those nodes certificates to then distribute those through configmanagement (ansible), that'd do it

With FAS, users can request/renew user cert through call to http://<fas_url>/dogencert.
For nodes, we had a custom wrapper script on the FAS node itself, that was using the CA to generate/sign CSR for nodes (nowhere to be seen in FAS, as there is no concept of node/host in FAS)

@tiran

This comment has been minimized.

Copy link

@tiran tiran commented Feb 10, 2020

Yes, it is possible to create host and service entries without enrolling the host or service with ipa-client-install. You also need to bypass some policy checks, too.

@frasertweedale is our expert for certificate related policies and permissions. Fraser, please advise.

@frasertweedale

This comment has been minimized.

Copy link

@frasertweedale frasertweedale commented Feb 10, 2020

The best approach is to create the host entries. As @tiran says, you do not need to have a such a host enrolled in IPA.

It is likely that the default profile, caIPAserviceCert, is appropriate for your use case, and therefore the default CA ACL hosts_services_caIPAserviceCert can be used (i.e. there is nothing more to configure w.r.t. CA ACLs). If you want to use a custom profile or issue the certs from a sub-CA, you'll have to (a) create the profile and/or sub-CA and (b) create a CA ACL that allows certificates to be issued to the hosts (using a hostgroup is recommended) with the indicated profile and CA.

Finally, in order to request the certificate, the operator principal (i.e. the principal executing the ipa cert-request command needs write access to the userCertificate attribute of the subject principal. If you use Certmonger to request and manage the certificates, the operator will be the host principal of the machine on which certmonger is running, and you can use the host/service managedby attribute to allow one host to write the userCertificate attribute of another host or service. If a user principal will be used to request the certificates, you will need to explicitly create the permissions.

@abompard

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 10, 2020

Thanks a lot @tiran and @frasertweedale Quick question on the side for @arrfab , how do you currently authenticate to the FAS endpoint?

@arrfab

This comment has been minimized.

Copy link

@arrfab arrfab commented Feb 10, 2020

@abompard : can you elaborate ? for the node cert we don't, as FAS doesn't support that at all, so , as mentioned on the previous comment, we (and Fedora was doing the same before) have (as sysadmin) a shell directly on FAS node with CA where we generate those nodes certs.
Other requirement btw : for CentOS Stream (and so mbox, because it runs in openshift) , we need SANs extensions through the cert-request too

@abompard

This comment has been minimized.

Copy link
Member

@abompard abompard commented Feb 11, 2020

OK let me see if I got it straight. Could this work for you @arrfab :

  • we (or you?) declare the hosts entries in IPA but don't enroll them
  • the machine where you have your ansible repo can have the ipa client installed (but not the nodes, that part is understood)
  • we set the managedby attribute on the node hosts in LDAP to the "ansible" machine
  • from that machine, you can generate CSRs and submit them to IPA using the ipa cert-request command for the node hosts, retrieve them locally and store them in your ansible repo
  • you use ansible to distribute those certs to the nodes
  • if you run certmonger on the ansible host, it can also regenerate those certs when they expire

Could that work?

@arrfab

This comment has been minimized.

Copy link

@arrfab arrfab commented Feb 11, 2020

Well, something like that, as yes, we were told that we'd have admin privs in IPA (as it's a shared instance for Fedora and CentOS) ;-)
We can have a node (but not the ansible management station) that can , on behalf of the nodes for which we want to have certs, request such certificates, and we can distribute those through Ansible later.

That would work for the nodes certs, and Securitas portal (or "new-name-to-be-found-because-naming-is-hard" ;-) ) should still provide an endpoint for a yet-to-be-written-cli-tool so that end users can also request a user certificates (I guess that one python client generating locally private key - if not existing yet - and creating CSRs , to be sent to securitas, itself forwarding to IPA API endpoint once authenticated, and then back with .crt back to requester would work)

@sfinn85

This comment has been minimized.

Copy link
Author

@sfinn85 sfinn85 commented Feb 19, 2020

Follow up with Fabian for further clarity on this, do we need to do anything from our side

@abompard abompard added the next phase label Feb 20, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
AAA
  
Backlog
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.