Skip to content
This repository has been archived by the owner on Apr 16, 2018. It is now read-only.

[dev.icinga.com #12439] Fetch the client ticket from the REST API (master) #355

Open
icinga-migration opened this issue Aug 15, 2016 · 3 comments

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/12439

Created by mfriedrich on 2016-08-15 13:28:13 +00:00

Assignee: (none)
Status: New
Target Version: (none)
Last Update: 2016-08-23 15:56:25 +00:00 (in Redmine)


Available with 2.5 - #12433


Relations:

@icinga-migration
Copy link
Author

Updated by mfriedrich on 2016-08-15 13:28:27 +00:00

  • Relates set to 12433

@icinga-migration
Copy link
Author

Updated by TheFlyingCorpse on 2016-08-23 15:53:02 +00:00

Note: requires a rewrite of the manifests/pki/icinga.pp since it no longer has a salt to generate certs from.

I could likely help here if it is decided a safe way to transport the ticket to the client.

Would an exported resource be ok? What other options are there?

Suggested approach:

  1. Icinga 2 node creates an exported resource that it wants a certificate
  2. Icinga 2 CA creates the certificate, stores ticket in a new exported resource for the server
  3. Icinga 2 node fetches the ticket via the exported resource and stores the certificate.

Questions:

  • What mechanisms to handle revoke or re-issuing.
  • What about DMZ where the Node talks to a satellite and not to the master/CA?
    (- How to not conflict with nodes not enrolled via puppet?)

@icinga-migration
Copy link
Author

Updated by TheFlyingCorpse on 2016-08-23 15:56:25 +00:00

Or as the ticket actually asks for.

Rewrite it to use the APi. I wrote down an old concept from earlier when using the old ticket method.

It wouldnt solve the API when talking to a satellite though, besides that is should be quite trivial. Let me try to do it with puppet as is.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant