Posts made by stacksofplates

Teleport may be a good option here. They have MFA baked in.

Nebula might also work, I'm not sure if they have MFA or not.

@dashrender said in Locking down vendors:

@pete-s said in Locking down vendors:

Yes, on a VLAN for each network.

If it's highly sensitive or for compliance, separate switches are needed for these networks to avoid vlan hopping or misconfigured switches that allow access to restricted network assets. Normally it's not needed though.

A separate firewall also sounds like it's not needed unless you have some serious security concerns.

ZeroTier doesn't sound like the best tool for the job though.

Something like OpenVPN with certificates and perhaps with added OTP is much better suited.

You want to give access to people on a time-limited basis. Certificates have expiration so that is great. OTP ensures that knowing passwords and having a certificate is not enough.

When clients log in they are put in a specific IP and you control their network access to their VLANs through your firewall's rules..

That way you have something that can grow. VPN provides access and security is handled in your firewall.

If you want something hosted (like ZeroTier is), I'd look into Cloudflare Access. They use wireguard for the VPN access and their network controls access.

What don't you like about ZeroTier? I do like the added security of the OTP, though I'm not sure if I need to go that far. ZT would be locked down to the single device. No clue if an install could be moved from one install of Windows to another...

You could set up the routes in ZT so they only have access when you want them to, but that is manual work.

You can't really do mfa since ZT is a layer 2 network.

There's also nothing stopping you from doing everything over HTTPS/SSH/whatever over zerotier. I just don't see the issue.

@notverypunny said in ZeroTier & Security:

Wondering what the overall opinion(s) are with regards to ZeroTier and information security / confidentiality when using a hosted controller.

I've had cursory discussions with other IT folks in the past and they seemed to be wary of ZT with regards to confidentiality and information security because:
-- Point 1 - ZT, in their own docs claims to basically emulate a L2 switch
-- Point 2 - L2 switches can be sniffed via span / mirror ports
-- Point 3 - As an IT pro you wouldn't connect your endpoints directly to someone else's L2 switch without due-diligence / NDA etc etc etc legalese necessary for colo and datacenter setups due to Point 2

They (ZT) also make the claim that data is E2E encrypted, "and can't be read by roots or anyone else"

I don't really see any reason to be concerned but if you are just run Tinc or Nebula.

This doesn't have ports so you can't sniff or mirror a port.

If it's encrypted, what's the concern with using it?

@dafyre said in What does your desk look like?:

@stacksofplates said in What does your desk look like?:

Such a neat looking desk. I'm too ashamed of the disaster area of mine to actually post anything.

I'm trying to make it a habit to keep it clean. It's tough though.

This site is pretty popular form what I've seen.

theorg.com/organizations

Not sure if this is what you're asking for or not.

@jimmy9008 said in VDI Options - Modernization:

@jt1001001 said in VDI Options - Modernization:

@jimmy9008 We have a use case involving a legacy client/server app that we've determined we're going to have to go VDI for in order to secure it. One lousy app for approx 5 users that I hope we eventually move away from. We are currently reviewing Azure VDI for this and it so far will fit the bill though we had to go throught a lot of "hoops" to configure networking, VPN back into our infrastructure, etc. We have not yet presented budget numbers to the bean counters but Im hoping when we do they will see the $$$$$ wasted for 5 users and will force them to a new product.

What other products do you plan to look at? Still VDI or something else? Any experience of VMWare Horizon?

We have around 600 - 1000 users globally (mostly developers) on the VDI I need to replace. The company dictates that the VDI must be in the same datacenter as the rest of the developers environments, so I don't think Azure VDI would work for us because of that mandate.

I know this isn't VDI, but what about something like GitPod, Eclipse Che, Coder, etc? In everyone's defense, developing over VDI truly sucks. This would keep the development environments in the same data center, but would give a much better experience.

@taurex said in Centralized Log Management:

Scott pretty much nailed it. Although collecting and preserving logs centrally is a good idea, analysing them anything but superficially would normally require a dedicated IT security team. There are (expensive) solutions like SIEM that make this job easier but even those can hardly be managed by a typical SMB/SME IT depts on their own. If the OP's organisation needs to be ISO 27001 certified or compliant with PCI, HIPAA etc. yet small enough, looking at MDR, MSSP or managed SIEM providers might be an alternative.

Opendistro/opensearch is an SIEM, same with Loki/Grafana or Graylog (even with the crappy licensing).

They don't have to be expensive and they can be relatively easy to set up reasonable alerting for events you need to know about.

Loki is another popular open source solution.

@travisdh1 said in Staying at your shitty employer is your fault:

How does my value to the company change because of where I happen to live?

https://about.gitlab.com/handbook/total-rewards/compensation/#paying-local-rates

@dashrender said in Staying at your shitty employer is your fault:

I've read that west coast companies are now starting to have a new baseline salary for a position, then up it based on where you actually live. So the base might be $80K, but if you live in SF, you get $40K/y more, but live in Wisconsin - you just get 80K.

This is the initial post. Dash stated this and then others had to jump in to argue. He is right, they do it. Whether anyone agrees or not with the idea is immaterial, it happens frequently so Dash was correct.

@pete-s said in Staying at your shitty employer is your fault:

@stacksofplates said in Staying at your shitty employer is your fault:

GitHub does the same, same with all FAANG. I've also interviewed at other tech companies that did the same. It's very common to pay the employee based on their primary location.

So after you're hired you'll get a raise if you move to a more expensive location?

According to that yes. It also goes the other way, if you move to a lower cost area it goes down.

@obsolesce said in Staying at your shitty employer is your fault:

@scottalanmiller said in Staying at your shitty employer is your fault:

@obsolesce said in Staying at your shitty employer is your fault:

What I've been told is that it goes by local market... based on the cost of labor in a given location, remote or not.

Whose local market, though?

The local market of the potential hire, for the job their being hired for.

Yeah this is common. Not sure what the argument is here. Most tech companies pay based on where the employee is living. GitLab is very public about this, they even have a whole page on their site dedicated to it. Their calculator used to be public but now is just for applicants.

GitHub does the same, same with all FAANG. I've also interviewed at other tech companies that did the same. It's very common to pay the employee based on their primary location.

@jaredbusch said in beyond bash shell scripting, what language should I use:

@scottalanmiller said in beyond bash shell scripting, what language should I use:

Go is great as a language. But like Ruby, not installed generally. And fewer resources. If it was a greenfield new OS, yeah, Go for sure. But for practical reasons, Python I think.

As these are systems that I control, there is no reason Go cannot be installed.

Between your comments and prior ones from @stacksofplates I think I might try Go in order to learn it.

You normally wouldn't install it anyway as it's not a scripting language. You'd just compile your binary and ship that to your systems.

@jaredbusch said in beyond bash shell scripting, what language should I use:

@stacksofplates said in beyond bash shell scripting, what language should I use:

Prob the best option for this use case is to choose based on the libraries available for what you want to do.

I assume that anything people recommend today would have most libraries.
But that is part of why I ask.

Yeah it depends. I've run into situations where the library might exist but it's garbage to use or just didn't exist, but you're right its not the norm anymore.

After spending the past 9-10 months writing microservices in Python I don't mind it. I used to not like it at all. This looks promising for Python:

https://github.com/kkroening/ffmpeg-python

This one for Go:

https://github.com/u2takey/ffmpeg-go

Another plus for Go here is concurrency. Go makes concurrency really easy.

@jaredbusch said in beyond bash shell scripting, what language should I use:

@obsolesce said in beyond bash shell scripting, what language should I use:

@jaredbusch said in beyond bash shell scripting, what language should I use:

@pete-s said in beyond bash shell scripting, what language should I use:

There is no general answer to your question.

There is. Just because you cannot see it doesn't mean it does not exist.

Each person's answer of a language is a general answer. Their reason for the recommendation allows me to see if it fits my need and skill and desire.

It might be an excuse to give Golang a whirl.

I have never done anything with it but I know @stacksofplates has done a bunch with it.

Yeah it all depends. Prob the best option for this use case is to choose based on the libraries available for what you want to do.

However if you just want a binary you can ship around easily then Go is a great choice.

@scottalanmiller said in Staying at your shitty employer is your fault:

@dashrender said in Staying at your shitty employer is your fault:

I've read that west coast companies are now starting to have a new baseline salary for a position, then up it based on where you actually live. So the base might be $80K, but if you live in SF, you get $40K/y more, but live in Wisconsin - you just get 80K.

That'll never work. There are ways to live in NYC for super cheap. There are ways to "live" one place but be based in another. Everyone will "move" to expensive locations when deals happen to screw the system. Letting the employees dictate their salaries based on a fungible concept is insane. Makes no sense to the employees, makes even less sense to an employer. If my employees make bad life decisions, why should I provide them a bonus for that?

This happens with most tech companies. Any I've looked at have paid differently based on where you live. And when covid hit there were reports those that weren't remote already were taking suit and when employees moves their pay changed based on location.

@pete-s said in GKE Auto Scaling down to shut down resource usage and save costs.:

@stacksofplates said in GKE Auto Scaling down to shut down resource usage and save costs.:

@pete-s said in GKE Auto Scaling down to shut down resource usage and save costs.:

@irj
Interesting, I know nothing but aren't you using the cluster autoscaler?

It's supposed to scale up and down automatically as needed with the settings you give it. If it doesn't scale down as far as you like, have a look at the settings.

Autoscaling depends on the apps. If your app can't withstand a shutdown it's not a good idea. When more nodes are added the scheduler might move the pod to a different machine.

Yes, but that is why you have settings. How far you want to be able to scale down and how far you want to be able to scale up.

But I don't know much about it though except what I've picked up from videos like the one below:

It's not really about cluster settings. Even adding one node can cause a pod to be rescheduled. Then the node has to download the container and start the app which could take quite a bit of time depending on your container size. The point was the only time to enable autoscaling is if you know your app can handle interruptions.