4 ms·

See, I do infrastructure work in companies that often don't even expose their services. They just want a database and a frontend for a very small internal app t

See, I do infrastructure work in companies that often don't even expose their services. They just want a database and a frontend for a very small internal app that will never get out. And yet, a lot of the tools are designed "for the web" and, rightfully so, enforce https, ssl, certs, you name it. Now the issue is that they are a real PITA to implement in some of those networks, where you have to use tons of private registries and repositories, and to get everything working with certificates. Because those companies are not used to issue certs, often times it take them months to do so, as they have a very rigorous process, so everyone wonders why this tiny app never goes to "production" and why we are blocked by such restrictions. Now I'm not even accounting for the fact that you sometimes actually need to go online to install some of those stuff. Recent example was node-sass, dependancy from a composer package, which you would expect to just install from the composer registry ; but no, it has a setup script that goes to nodejs.org or something, which of course you cannot fake because it will have to check certs as well. So again, something designed for the web that'll never work seemlessly elsewhere. (There are workaround of course but I'd love to spend my time elsewhere). To give you an idea, the cloud I'm working on right now is pretty much entirely offline, for both egress and ingress. There is a nexus mirror-proxy to dockerhub and that's it, even this is in the LAN. So really, having to configure cockroachdb certs (or anything else for that matter, like etcd...) is useless, time consuming, frustrating, and counterproductive.

dkersten 7y ago
> very small internal app Is cockroachdb the right DB for this use case, though? A more traditional Postgres/MySQL or evening sqlite (depending on needs) is often plenty good for a small internal app without requiring this extra security > the cloud I’m working on right now is pretty much entirely offline I fee like “cloud” has lost all meaning it may have once had
- bionsystem 7y ago
  > Is cockroachdb the right DB for this use case, though? A more traditional Postgres/MySQL or evening sqlite (depending on needs) is often plenty good for a small internal app without requiring this extra security It's not, but the app I described is just an example. Some use cases involve bigger dataset and resilience. It's not cockroachdb specifically but any of those "web" tools that, used internally in a closed environment, become a PITA to manage. Language tooling, repositories, dbs... Etcd for example is used as an internal storage for tenants (for example to store DNS information) and the team that manages it cannot upgrade right now because they have to figure out first how to implement ssl. > I fee like “cloud” has lost all meaning it may have once had Well, how would you call an on-prem install of OpenStack ? It's their internal cloud. Cloud has not much to do with the web or with the fact that it is publicly exposed, it's a tool to manage infrastructure. And to be perfectly honest, "cloud" isn't a proper term to begin with. Years ago when the word came out one of my professor said they basically renamed "grid" to "cluster" then "cloud". They used to administer hundreds+ of machines and multiples of that of jobs using pssh. They didn't wait for kube, and they didn't need ssl between each and every API and services. Now don't get me wrong, the public cloud provides a great service and tooling coming out now should be web ready and web safe. Just, please, pretty please, give us a --insecure and --offline even if it means having it all over my ansible code, so we can get the job done without having to spend my days working around those tools.
  - dkersten 7y ago
    That sounds reasonable, thanks for the detailed response. > And to be perfectly honest, "cloud" isn't a proper term to begin with. Completely agree, it’s just a marketing buzzword.
  - irfansharif 7y ago
    > Just, please, pretty please, give us a --insecure Have you taken a look at [0]? (All caveats around running an insecure cluster apply) [0]: https://www.cockroachlabs.com/docs/stable/deploy-cockroachdb-on-premises-insecure.html https://www.cockroachlabs.com/docs/stable/deploy-cockroachdb...
- brianmcc 7y ago
  the built in resilience via N nodes of something like CRDB can be useful even with super-small-scale data/traffic
imtringued 7y ago
You don't need a publicly signed certificate if the services are only used internally. It's not like you want people to look at your database with a browser anyway. All you need to is create a private CA and then two private keys/certificates (one for server, one for client) sign it with the CA and add the server certificate to the database, add the client certificate to your web server that accesses the database and finally add the self signed CA to both database and webserver. There is no cryptographic security benefit of publicly vs privately signed certificates. After all publicly signed certificates are just privately signed certificates whose CA has been added to your CA store. So just add your own CA to whatever program is needed (do not add your own CA to the whole system). The annoyance is keeping those certificates and CAs up to date. Tools like Hashicorp Vault can automatically generate certificates for you if you want to automate this part.

dkersten 7y ago

> very small internal app Is cockroachdb the right DB for this use case, though? A more traditional Postgres/MySQL or evening sqlite (depending on needs) is often plenty good for a small internal app without requiring this extra security > the cloud I’m working on right now is pretty much entirely offline I fee like “cloud” has lost all meaning it may have once had

bionsystem 7y ago
> Is cockroachdb the right DB for this use case, though? A more traditional Postgres/MySQL or evening sqlite (depending on needs) is often plenty good for a small internal app without requiring this extra security It's not, but the app I described is just an example. Some use cases involve bigger dataset and resilience. It's not cockroachdb specifically but any of those "web" tools that, used internally in a closed environment, become a PITA to manage. Language tooling, repositories, dbs... Etcd for example is used as an internal storage for tenants (for example to store DNS information) and the team that manages it cannot upgrade right now because they have to figure out first how to implement ssl. > I fee like “cloud” has lost all meaning it may have once had Well, how would you call an on-prem install of OpenStack ? It's their internal cloud. Cloud has not much to do with the web or with the fact that it is publicly exposed, it's a tool to manage infrastructure. And to be perfectly honest, "cloud" isn't a proper term to begin with. Years ago when the word came out one of my professor said they basically renamed "grid" to "cluster" then "cloud". They used to administer hundreds+ of machines and multiples of that of jobs using pssh. They didn't wait for kube, and they didn't need ssl between each and every API and services. Now don't get me wrong, the public cloud provides a great service and tooling coming out now should be web ready and web safe. Just, please, pretty please, give us a --insecure and --offline even if it means having it all over my ansible code, so we can get the job done without having to spend my days working around those tools.
- dkersten 7y ago
  That sounds reasonable, thanks for the detailed response. > And to be perfectly honest, "cloud" isn't a proper term to begin with. Completely agree, it’s just a marketing buzzword.
- irfansharif 7y ago
  > Just, please, pretty please, give us a --insecure Have you taken a look at [0]? (All caveats around running an insecure cluster apply) [0]: https://www.cockroachlabs.com/docs/stable/deploy-cockroachdb-on-premises-insecure.html https://www.cockroachlabs.com/docs/stable/deploy-cockroachdb...
brianmcc 7y ago
the built in resilience via N nodes of something like CRDB can be useful even with super-small-scale data/traffic

imtringued 7y ago

You don't need a publicly signed certificate if the services are only used internally. It's not like you want people to look at your database with a browser anyway. All you need to is create a private CA and then two private keys/certificates (one for server, one for client) sign it with the CA and add the server certificate to the database, add the client certificate to your web server that accesses the database and finally add the self signed CA to both database and webserver. There is no cryptographic security benefit of publicly vs privately signed certificates. After all publicly signed certificates are just privately signed certificates whose CA has been added to your CA store. So just add your own CA to whatever program is needed (do not add your own CA to the whole system). The annoyance is keeping those certificates and CAs up to date. Tools like Hashicorp Vault can automatically generate certificates for you if you want to automate this part.