4 ms·

> why isn't what's good for the bastion good enough for the rest of the fleet? mfdutra's comment that you replied to said: If things go south really really bad

by timv 10y ago

> why isn't what's good for the bastion good enough for the rest of the fleet? mfdutra's comment that you replied to said: If things go south really really bad, we can just get the private key and sign certificates by hand. That's obviously an incomplete answer - it doesn't explain how you connect to the server if you can't get onto the bastion due to a directory failure - but the basic premise is that the core system is isolated & contains everything it needs to handle the authentication process.

otterley 10y ago
That doesn't answer my question at all.
- timv 10y ago
  I'll assume that you didn't mean that to be as snarky as it sounds. The bastion host is not strictly necessary in the process. Although mfdutra didn't spell it out explicitly, they clearly have a means for accessing their core servers without needing to get on to the bastion - that's where the signing by hand comes in. The benefits of using LDAP in that case justify the cost of having an external dependency - by integrating with the central password store, the bastion provides a path into the system that delivers the desired security features (centralised identity management, auditing back to individual user accounts), but other paths can exist if needed. That trade-off isn't applicable to core servers. If they use LDAP (exclusively) for authentication and the directory is down then you're hosed. There's no other path into the server that you're trying to admin other than to get onto the server. You could use LDAP with a fallback to some other scheme (like signed certs, or a small set of locally defined users managed with a password vault, etc) but then you've got 2 different paths onto each server and both paths needs to be maintained, tested, and regularly audited. That's certainly possible, but why would you want to when you can just have 1 authentication mechanism that has zero dependencies.
  - otterley 10y ago
    I dislike guessing what someone's intent and rationale are, when we can simply ask, as we can here. In any event: First, the CA itself is a dependency: if it fails, no login certificates will issue, and users won't be able to log in. So they traded one kind of service dependency for another. Second, it hasn't been established that a backup login path is available. In many environments this may not even be acceptable (e.g. PCI and billing systems, which I know Facebook has).
    - superuser2 10y ago
      >service dependency A CA is just some bytes, not a service. And it has been established that there's a backup login path: use (a copy of) the CA outside of the automated certificate signing service to manually sign the needed certificates. They'd be screwed if they lost the CA's private key, but it is much easer to keep some data around than to keep a service functioning properly.
      - otterley 10y ago
        You're mistaking the CA certificate (i.e. the certificate that signs the login certificate) for the signing process itself. In the scheme described, users don't log into servers with the CA's certificate and private key -- the CA's private key is always protected, preferably in an HSM of some sort. Instead, the CA issues a signed certificate to the user with a set of principals; and that latter certificate is the one used to log in. So, the process that issues certificates (the "Authority", as opposed to the "Authority Certificate") is the one I'm concerned with here.
        superuser2 10y ago
        No I'm not. >If things go south really really bad, we can just get the private key and sign certificates by hand. Very clearly states that someone has access to the CA cert's private key outside the context of the automated signing service, and can use it to manually sign certs for users if the CA service is down. So the CA service can be bypassed if it goes down,.
- tacticus 10y ago
  You have a panic room/war room or etc. Somewhere with significant physical security and dedicated ports that skips the bastion entirely. You might have to go for the axe method in getting into the room during an incident but you can if need be.
  - otterley 10y ago
    You can do that even if LDAP is your primary authentication method. NSS and PAM have supported fallback methods since their inception, nearly two decades ago.
  - deleted 10y ago
    [deleted]

by timv 10y ago

otterley 10y ago

That doesn't answer my question at all.

timv 10y ago
I'll assume that you didn't mean that to be as snarky as it sounds. The bastion host is not strictly necessary in the process. Although mfdutra didn't spell it out explicitly, they clearly have a means for accessing their core servers without needing to get on to the bastion - that's where the signing by hand comes in. The benefits of using LDAP in that case justify the cost of having an external dependency - by integrating with the central password store, the bastion provides a path into the system that delivers the desired security features (centralised identity management, auditing back to individual user accounts), but other paths can exist if needed. That trade-off isn't applicable to core servers. If they use LDAP (exclusively) for authentication and the directory is down then you're hosed. There's no other path into the server that you're trying to admin other than to get onto the server. You could use LDAP with a fallback to some other scheme (like signed certs, or a small set of locally defined users managed with a password vault, etc) but then you've got 2 different paths onto each server and both paths needs to be maintained, tested, and regularly audited. That's certainly possible, but why would you want to when you can just have 1 authentication mechanism that has zero dependencies.
- otterley 10y ago
  I dislike guessing what someone's intent and rationale are, when we can simply ask, as we can here. In any event: First, the CA itself is a dependency: if it fails, no login certificates will issue, and users won't be able to log in. So they traded one kind of service dependency for another. Second, it hasn't been established that a backup login path is available. In many environments this may not even be acceptable (e.g. PCI and billing systems, which I know Facebook has).
  - superuser2 10y ago
    >service dependency A CA is just some bytes, not a service. And it has been established that there's a backup login path: use (a copy of) the CA outside of the automated certificate signing service to manually sign the needed certificates. They'd be screwed if they lost the CA's private key, but it is much easer to keep some data around than to keep a service functioning properly.
    - otterley 10y ago
      You're mistaking the CA certificate (i.e. the certificate that signs the login certificate) for the signing process itself. In the scheme described, users don't log into servers with the CA's certificate and private key -- the CA's private key is always protected, preferably in an HSM of some sort. Instead, the CA issues a signed certificate to the user with a set of principals; and that latter certificate is the one used to log in. So, the process that issues certificates (the "Authority", as opposed to the "Authority Certificate") is the one I'm concerned with here.
      - superuser2 10y ago
        No I'm not. >If things go south really really bad, we can just get the private key and sign certificates by hand. Very clearly states that someone has access to the CA cert's private key outside the context of the automated signing service, and can use it to manually sign certs for users if the CA service is down. So the CA service can be bypassed if it goes down,.
tacticus 10y ago
You have a panic room/war room or etc. Somewhere with significant physical security and dedicated ports that skips the bastion entirely. You might have to go for the axe method in getting into the room during an incident but you can if need be.
- otterley 10y ago
  You can do that even if LDAP is your primary authentication method. NSS and PAM have supported fallback methods since their inception, nearly two decades ago.
- deleted 10y ago
  [deleted]