5 ms·

This is Drew's position: https://paste.sr.ht/~sircmpwn/78cc21e1661d5a9d8038f47e532d286807ac89ad https://paste.sr.ht/~sircmpwn/78cc21e1661d5a9d8038f47e532d28...

by js2 4y ago

sph 4y ago
Pretty feeble argument. Basically it boils down to "if you use Docker you risk not learning how it works and hurting yourself." As I mention in the sibling comment, it would feel less patronising just saying out loud "we do not like containers, roll your own."
- bayindirh 4y ago
  I don't think so. I was researching Keycloak integration with Kubernetes (a project needed it at the office). I installed it on bare metal, set-up its TLS certificates and enabled native HTTPS. While searching for integration I found a video. The person installed Keycloak Docker image, and dropped an HTTPS proxy container in front of it to enable TLS/HTTPS. If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is. The person didn't learn how to use and administer Keycloak, didn't make good judgement calls about security and published bad information while doing that. Docker is easy to abuse and creates people who think know stuff, but do not in reality. Docker. Pull Responsibly (TM).
  - sph 4y ago
    Oh, so there's people that don't know how to use containers, so they're bad? What kind of patronising, nanny state kind of argument is that? Listen, I understand not liking containers. That's fine. But just say so, or try to give more concrete arguments to the table than "I saw a guy in a video creating an insecure container. Thus Docker creates ignorance." As if configuring servers by hand isn't prone to misconfiguration or bad security practices. Perhaps we have namespaces today because people have been creating insecure, unmaintainable pet systems since the stone age, yet it doesn't save you from hurting yourself if you don't know what you're doing.
    - bayindirh 4y ago
      > Oh, so there's people that don't know how to use containers, so they're bad? What kind of patronising, nanny state kind of argument is that? You're building rest of your comment on this misinterpretation of my comment. What I say is "Docker is easy, but it lowers the bar for making mistakes too much. Using Docker without enough information creates bigger problems, faster". You can do a lot of mistakes, and fatal ones at that, while working on bare metal too. I'm managing systems for 15+ years, using Linux close to 20, and had my fair share on any abstraction level (metal, VM, container, etc.). However, K8S and Docker is susceptible to create a whole set of problems, and more importantly without knowing it, until it's too late. VMs and bare metal fail relatively early and with more noise. If you do something wrong with your K8S deployment, you can't mend it, and need to re-deploy it. I do not prefer Docker and K8S, and avoid the latter if I can, but I'm not an hard-line extremist against any of them. I also manage containers and a K8S cluster at work, too. And no, I never patronize anyone. This is not my style. I just shared my experience, and told that "learning wrong things is easier with Docker", that's all. I know excellent developers and sysadmins who do wonders with containers, too. Docker and K8S are sharp knives with no warnings on them. That's all.
      - sph 4y ago
        > Docker and K8S are sharp knives with no warnings on them. And that's nothing wrong with that. You might also "hurt" yourself by installing software by hand. Let's agree to disagree, this "it could be dangerous!" argument feels like doubling down on a weak position, but I honestly do not care about fighting someone over the internet about it. Your computer, your rules :-)
        bayindirh 4y ago
        > And that's nothing wrong with that. Yes, except poor documentation and lots of open secrets. There is no need to fight. We're just discussing. We can do things differently and obtain the same brilliant or disastrous results regardless of the underlying abstraction layer/platform. All approaches have advantages and disadvantages, so all takes are equally weak IMHO. Have a nice day, Cheers.
  - KronisLV 4y ago
    > I installed it on bare metal, set-up its TLS certificates and enabled native HTTPS. While searching for integration I found a video. The person installed Keycloak Docker image, and dropped an HTTPS proxy container in front of it to enable TLS/HTTPS. > If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is. Would you mind sharing your argumentation about this, both in the context of Keycloak and in general? In my eyes, enabling TLS on whatever application you want to run directly is almost always a bad choice, because you now need to deal with its unique implementation, as well as any vulnerabilities that the implementation could have. For example, even if all of your services run Java, you might find that a Spring application, a Spring Boot application, a Quarkus and a Vert.X application all have different ways of enabling it: Spring example: https://www.baeldung.com/spring-channel-security-https Spring Boot example: https://www.baeldung.com/spring-boot-https-self-signed-certificate Quarkus example: https://quarkus.io/guides/http-reference#ssl Vert.X example: https://github.com/eclipse-vertx/vert.x/blob/master/src/main/java/examples/EventBusExamples.java#L106 (couldn't even find docs) And that's before you have parts of your stack running Node, Python, .NET, Ruby, PHP, Go or whatever else you might have to deal with. You can basically forget about automatically provisioning ACME certificates through Let's Encrypt, as well as being able to (easily) have all of your certificates in one place (at least for whatever that node needs), for easier renewals. This is especially noticeable when you want to serve dozens of different sites/applications from the same node. In contrast, when you have a web server as your point of ingress, that then acts as a transparent reverse proxy in front of your applications: - it takes care of all of the certificates, in a common format, they're easy to renew or can be provisioned thanks to ACME - it can take care of other concerns, like path rewriting, HTTP to HTTPS redirects, rate limiting, additional caching or headers - your applications can talk to one another in the internal network through HTTP, whereas encryption there can be added transparently - with containers, this might be an overlay network where the clustering/networking solution takes care of internal certificates and rotates them often So, how is that a bad choice? Some reasonable arguments that I can come up with are: - it's easier to screw things up and expose stuff directly (e.g. port mappings, instead of overlay networks) - one could feasibly argue that sometimes the application itself might want to look at the certificates and do something with them (e.g. expiry alerts) - one could also argue that reverse proxies won't necessarily be perfect and some software might not correctly deal with headers Perhaps I'm missing something that's staring me in the face.

This is Drew's position: https://paste.sr.ht/~sircmpwn/78cc21e1661d5a9d8038f47e532d286807ac89ad https://paste.sr.ht/~sircmpwn/78cc21e1661d5a9d8038f47e532d28...

by js2 4y ago

This is Drew's position: https://paste.sr.ht/~sircmpwn/78cc21e1661d5a9d8038f47e532d286807ac89ad https://paste.sr.ht/~sircmpwn/78cc21e1661d5a9d8038f47e532d28...

sph 4y ago

Pretty feeble argument. Basically it boils down to "if you use Docker you risk not learning how it works and hurting yourself." As I mention in the sibling comment, it would feel less patronising just saying out loud "we do not like containers, roll your own."

bayindirh 4y ago
I don't think so. I was researching Keycloak integration with Kubernetes (a project needed it at the office). I installed it on bare metal, set-up its TLS certificates and enabled native HTTPS. While searching for integration I found a video. The person installed Keycloak Docker image, and dropped an HTTPS proxy container in front of it to enable TLS/HTTPS. If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is. The person didn't learn how to use and administer Keycloak, didn't make good judgement calls about security and published bad information while doing that. Docker is easy to abuse and creates people who think know stuff, but do not in reality. Docker. Pull Responsibly (TM).
- sph 4y ago
  Oh, so there's people that don't know how to use containers, so they're bad? What kind of patronising, nanny state kind of argument is that? Listen, I understand not liking containers. That's fine. But just say so, or try to give more concrete arguments to the table than "I saw a guy in a video creating an insecure container. Thus Docker creates ignorance." As if configuring servers by hand isn't prone to misconfiguration or bad security practices. Perhaps we have namespaces today because people have been creating insecure, unmaintainable pet systems since the stone age, yet it doesn't save you from hurting yourself if you don't know what you're doing.
  - bayindirh 4y ago
    > Oh, so there's people that don't know how to use containers, so they're bad? What kind of patronising, nanny state kind of argument is that? You're building rest of your comment on this misinterpretation of my comment. What I say is "Docker is easy, but it lowers the bar for making mistakes too much. Using Docker without enough information creates bigger problems, faster". You can do a lot of mistakes, and fatal ones at that, while working on bare metal too. I'm managing systems for 15+ years, using Linux close to 20, and had my fair share on any abstraction level (metal, VM, container, etc.). However, K8S and Docker is susceptible to create a whole set of problems, and more importantly without knowing it, until it's too late. VMs and bare metal fail relatively early and with more noise. If you do something wrong with your K8S deployment, you can't mend it, and need to re-deploy it. I do not prefer Docker and K8S, and avoid the latter if I can, but I'm not an hard-line extremist against any of them. I also manage containers and a K8S cluster at work, too. And no, I never patronize anyone. This is not my style. I just shared my experience, and told that "learning wrong things is easier with Docker", that's all. I know excellent developers and sysadmins who do wonders with containers, too. Docker and K8S are sharp knives with no warnings on them. That's all.
    - sph 4y ago
      > Docker and K8S are sharp knives with no warnings on them. And that's nothing wrong with that. You might also "hurt" yourself by installing software by hand. Let's agree to disagree, this "it could be dangerous!" argument feels like doubling down on a weak position, but I honestly do not care about fighting someone over the internet about it. Your computer, your rules :-)
      - bayindirh 4y ago
        > And that's nothing wrong with that. Yes, except poor documentation and lots of open secrets. There is no need to fight. We're just discussing. We can do things differently and obtain the same brilliant or disastrous results regardless of the underlying abstraction layer/platform. All approaches have advantages and disadvantages, so all takes are equally weak IMHO. Have a nice day, Cheers.
- KronisLV 4y ago
  > I installed it on bare metal, set-up its TLS certificates and enabled native HTTPS. While searching for integration I found a video. The person installed Keycloak Docker image, and dropped an HTTPS proxy container in front of it to enable TLS/HTTPS. > If this is not both bad practice and being misinformed about Keycloak in one step, I don't know what it is. Would you mind sharing your argumentation about this, both in the context of Keycloak and in general? In my eyes, enabling TLS on whatever application you want to run directly is almost always a bad choice, because you now need to deal with its unique implementation, as well as any vulnerabilities that the implementation could have. For example, even if all of your services run Java, you might find that a Spring application, a Spring Boot application, a Quarkus and a Vert.X application all have different ways of enabling it: Spring example: https://www.baeldung.com/spring-channel-security-https Spring Boot example: https://www.baeldung.com/spring-boot-https-self-signed-certificate Quarkus example: https://quarkus.io/guides/http-reference#ssl Vert.X example: https://github.com/eclipse-vertx/vert.x/blob/master/src/main/java/examples/EventBusExamples.java#L106 (couldn't even find docs) And that's before you have parts of your stack running Node, Python, .NET, Ruby, PHP, Go or whatever else you might have to deal with. You can basically forget about automatically provisioning ACME certificates through Let's Encrypt, as well as being able to (easily) have all of your certificates in one place (at least for whatever that node needs), for easier renewals. This is especially noticeable when you want to serve dozens of different sites/applications from the same node. In contrast, when you have a web server as your point of ingress, that then acts as a transparent reverse proxy in front of your applications: - it takes care of all of the certificates, in a common format, they're easy to renew or can be provisioned thanks to ACME - it can take care of other concerns, like path rewriting, HTTP to HTTPS redirects, rate limiting, additional caching or headers - your applications can talk to one another in the internal network through HTTP, whereas encryption there can be added transparently - with containers, this might be an overlay network where the clustering/networking solution takes care of internal certificates and rotates them often So, how is that a bad choice? Some reasonable arguments that I can come up with are: - it's easier to screw things up and expose stuff directly (e.g. port mappings, instead of overlay networks) - one could feasibly argue that sometimes the application itself might want to look at the certificates and do something with them (e.g. expiry alerts) - one could also argue that reverse proxies won't necessarily be perfect and some software might not correctly deal with headers Perhaps I'm missing something that's staring me in the face.