Language:
switch to room list switch to menu My folders
Go to page: First ... 16 17 18 19 [20]
[#] Tue Jul 20 2021 19:11:07 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

2021-07-20 15:52 from Nurb432
In our cases its specific 'apps' these people provide, so locking
them down is the best way to go.

That's very different from the use-cases I've been working on for the last 10 years. I'm currently working at the second company (an app provider, I guess you could say) where everything we do is hosted in the cloud. All our operations. We could have hosted in a traditional colocation datacenter, but for newly-launched businesses, the cloud has replaced that.

So from the standpoint of our operational philosophy, the goal (not always achieved in practice, just a goal) is that every Amazon EC2 instance that we launch (or Docker container running on an ECS cluster) is sort of an anonymous worker bee, part of the hive. Machines may not stay around very long. In fact, it's better if they don't, so we can relaunch it fresh, with the latest kernel patches, and we don't get into a situation where we have a stateful machine that has an uptime of 643 days that nobody dares to touch.

Machines should be as stateless as possible and some companies prefer to relauinch a new EC2 instance on every deployment, just to enforce the best practice that machine launches are always automated and scripted, never involve manual intervention.

There's a lot more to unpack about this, but I'll stop there. We don't need, require, or offer VPN connectivity to our customers (yet), but if we did, I suppose we might find a way to present a static *internal* IP to them if we had to. We can do static external IPs through Amazon's "Elastic IP" feature.

What I'm suggesting here, is that for customers who demand it, a static IP might be an abstraction that a service-provider might present, but internally there might be a swarm of ephemeral worker bees with short-lived dynamic IPs behind the scenes.

[#] Tue Jul 20 2021 19:34:05 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Ya, sounds like we are in different environments.  Our way would not work for you, and vise-versa 



[#] Fri Jul 23 2021 14:13:02 EDT from IGnatius T Foobar

[Reply] [ReplyQuoted] [Headers] [Print]

In a cloud environment, things like security and name services are often handled out of band.  If you're implementing their whole stack, the IP address doesn't matter a whole lot.

In a good cloud environment, launching a virtual machine that is intended to be persistent ought to offer an address lease that is long enough that it is essentially permanent, because in the real world, people use IP addresses.

"Cloud native" software doesn't care because it will usually do something like start itself up and then register with a load balancer.



[#] Fri Jul 23 2021 17:22:37 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Which in our case, would have the static IP.  

I agree consumers wont care about what is behind it. .  But we care about the LB

Fri Jul 23 2021 02:13:02 PM EDT from IGnatius T Foobar

"Cloud native" software doesn't care because it will usually do something like start itself up and then register with a load balancer.

 



[#] Sun Jul 25 2021 11:56:22 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]

In a good cloud environment, launching a virtual machine that is
intended to be persistent ought to offer an address lease that is
long enough that it is essentially permanent, because in the real
world, people use IP addresses.

This is the way it works in Amazon EC2:

* When you launch a machine, its internal IP is assigned dynamically but is essentially permanent and lasts for the life of the machine. That may not be nearly enough for people who want the ability to *relaunch* that machine on different hardware and keep the same IP.
* In that case, there are things you can do in VPC to hardcode an IP.
* You can also get static external/public IPs with the Elastic IP feature.

* But at scale, this kind of staticness may not work for every use case. We want to keep machines ephemeral and short-lived worker bees
* There are use-cases like the `awsvpc` network mode, which allows you to spin up a Docker container on ECS with its own dynamically allocated internal IP, which are not compatible with any kind of staticness.

[#] Sun Jul 25 2021 11:58:32 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


OBTW, amazon's native load-balancer product (1st-generation ELBs, 2nd-generation ALBs/NLBs) cannnot have static listen addresses. If you want that, I'm pretty sure you're rolling your own.

[#] Sun Jul 25 2021 12:01:56 EDT from LoanShark

[Reply] [ReplyQuoted] [Headers] [Print]


Crikey, I need to be careful when I say Amazon doesn't have a certain feature. I end up eating crow because that's a moving target, and I'm already the old guy in the room.

Amazon *can* do static public IP - on an NLB. So this article sketches out a somewhat Rube Goldbergian method where you can use an NLB (with static IP) to the front of all your other stuff: https://aws.amazon.com/blogs/networking-and-content-delivery/using-static-ip-addresses-for-application-load-balancers/

There's more moving parts here, which sounds clunky, but you can do it.

[#] Sun Jul 25 2021 14:39:50 EDT from Nurb432

[Reply] [ReplyQuoted] [Headers] [Print]

Until your 2nd comment, I was going to say i dont know how they are doing it, its all in the vendors hands so it could have been 'magic'.  We just said ' we need static ' and they made it happen. These are via non-public addresses routing only across the VPN, but i think the public side is too. While we added friendly A record DNS entries for what they gave us on public facing, id imagine they needed to be static. Or what they gave us was an A-record type of thing on Amazon side. Donno if that is how it is, or if that would even work, as never needed to look that far into it: "its the vendors problem".  But the internal traffic is 100% IP. 

They do have a problem that when they rebuild a server they cant pre-define the IP or set it themselves afterwards ( only the subnet ). Might get the same IP address back, but chances are slim. This hosed us a couple of times, as they forgot to tell us they did it and it changed, so everything we had internal broke. ( after the 2nd time we did open the entire subnet on the few ports we needed so down stream to us didnt need changing on the firewalls. but anything we were doing back up the VPN to them of course was hitting servers that no longer existed )

Tho all that said, this winter ( or coming spring ) we get moved to Azure, so all bets may be off?

 

 

Short story short of WHY we do this:

  • They provide a web based app, hosted on windows servers + MSSQL, now under their control being hosted in their AWS cloud. It used to be on site ( had a temporary CTO that basically said ' if your vendor supports it you are moving to cloud" even if it didnt make sense for your app ). Id love to move it back. Been nothing but problems since we moved.
  • Automation on their end reaches back down to things on our network for bits and pieces. Some of it read-only some R/W. So ports have to be open. Stuff like AD, or SCCM, solar winds, on-site SQL servers and various API calls to other apps we have. Some of our apps also reach back up to their SQL But all things that do NOT go across the internet.
  • Reporting runs on site, so i have to reach back to their SQL servers. Same here, no internet access to SQL. While its technically possible of course, security team would take us about back and shoot us. The data in there is way to sensitive to allow it.
  • The front end for users, IS availble on internet. As is their API. We jumped thru hoops for several years ( unrelated to the AWS move ), and finally got approval for internet facing, IF we had SSL ( duh ), SSO + MFA. ( and its subject to be pulled at any time ) So web clients, 90% no VPN for them.   Problem is 10% of my users cant do SSO/MFA as they are not part of our Azure tenant, so they have to access the web app across the site to site VPN and be on our network, or stop using the system.   Randomly changing IPS would effect them too.  Another agency that is trying to get their own install since we are not secure enough for them to share ours, i guess they are limiting who can use SSO by login, forcing their admin logins to be onsite. In my case its AD-forest based, and not a planned restriction, i just cant do it.
Being internet facing may go away soon, huge project where everyone has to re-justify it. Many are not able to. "convenience for our users" is not a valid reason anymore. 
 
 
The app, holds up our entire operation, and for what it does not do native, it still ties in to pretty much every process we have, and is a major part of several other agencies too. Its as integral as email so not trivial. Ya, a single point of failure, but sometimes its hard to avoid it. So we have contingency plans in place if perhaps AWS would go away for more than a few hours, or the vendor suddenly vanished ( we mandated a daily onsite backup, + we would just rebuild the app servers locally ). 
 
But hey, i have a 2nd guy that works with me now. It used to be me, and only me, for almost 2 decades. Its nice to be able to take a day off once in a while. While we did sort of divide up the work between us based on module, we do know everything so can fill in once in a while.
 
Long winded. sorry :)
 
Sun Jul 25 2021 11:58:32 AM EDT from LoanShark

OBTW, amazon's native load-balancer product (1st-generation ELBs, 2nd-generation ALBs/NLBs) cannnot have static listen addresses. If you want that, I'm pretty sure you're rolling your own.

 



Go to page: First ... 16 17 18 19 [20]