Why securing internet-facing applications is challenging in a Kubernetes environment
Internet-facing applications are some of the most targeted workloads by threat actors. Securing this type of application is a must in order to protect your network, but this task is more complex in Kubernetes than in traditional environments, and it poses some challenges. Not only are threats magnified in a Kubernetes environment, but internet-facing applications in Kubernetes are also more vulnerable than their counterparts in traditional environments. Let’s take a look at the reasons behind these challenges, and the steps you should take to protect your Kubernetes workloads.
Threats are magnified in a Kubernetes environment
One of the fundamental challenges in a Kubernetes environment is that there is no finite set of methods that exist in terms of how workloads can be attacked. This means there are a multitude of ways an internet-facing application could be compromised, and a multitude of ways that such an attack could propagate within the environment.
Kubernetes is designed in such a way that allows anything inside a cluster to communicate with anything else inside the cluster by default, essentially giving an attacker who manages to gain a foothold unlimited access and a large attack surface. Because of this design, any time you have Continue reading
Hedge 101: In Situ OAM
Understanding the flow of a packet is difficult in modern networks, particularly data center fabrics with their wide fanout and high ECMP counts. At the same time, solving this problem is becoming increasingly important as quality of experience becomes the dominant measure of the network. A number of vendor-specific solutions are being developed to solve this problem. In this episode of the Hedge, Frank Brockners and Shwetha Bhandari join Alvaro Retana and Russ White to discuss the in-situ OAM work currently in progress in the IPPM WG of the IETF.
5G Slicing: 4 Crucial Principles for Successful Implementation
5G network slicing enables providers to offer highly granular control over how users consume and create customized network slices.Day Two Cloud 116: Emotional Intelligence, Hard Conversations, And Other Essential Management Skills
Guest Shelley Benhoff stops by the Day Two Cloud podcast to discuss essential skills for moving into tech management, and how to decide if management is the right career path for you. Shelley has twenty years' experience in IT as a developer and manager, runs a tech training company, and is a Pluralsight instructor.
The post Day Two Cloud 116: Emotional Intelligence, Hard Conversations, And Other Essential Management Skills appeared first on Packet Pushers.
Day Two Cloud 116: Emotional Intelligence, Hard Conversations, And Other Essential Management Skills
Guest Shelley Benhoff stops by the Day Two Cloud podcast to discuss essential skills for moving into tech management, and how to decide if management is the right career path for you. Shelley has twenty years' experience in IT as a developer and manager, runs a tech training company, and is a Pluralsight instructor.AWS Networking – Part VI: Subnet to Route Table Association
At this phase, we have attached subnets to their respective Availability Zones. Next, we will create subnet-specific route tables for both Public and Private subnets.
Figure 1-25: VPC Subnets: Select VPC.
Continue reading
IS-IS Flooding Details
Last week I published an unrolled version of Peter Paluch’s explanation of flooding differences between OSPF and IS-IS. Here’s the second part of the saga: IS-IS flooding details (yet again, reposted in a more traditional format with Peter’s permission).
In IS-IS, DIS1 is best described as a “baseline benchmark” – a reference point that other routers compare themselves to, but it does not sit in the middle of the flow of updates (Link State PDUs, LSPs).
A quick and simplified refresher on packet types in IS-IS: A LSP carries topological information about its originating router – its System ID, its links to other routers and its attached prefixes. It is similar to an OSPF LSU containing one or more LSAs of different types.
IS-IS Flooding Details
Last week I published an unrolled version of Peter Paluch’s explanation of flooding differences between OSPF and IS-IS. Here’s the second part of the saga: IS-IS flooding details (yet again, reposted in a more traditional format with Peter’s permission).
In IS-IS, DIS1 is best described as a “baseline benchmark” – a reference point that other routers compare themselves to, but it does not sit in the middle of the flow of updates (Link State PDUs, LSPs).
A quick and simplified refresher on packet types in IS-IS: A LSP carries topological information about its originating router – its System ID, its links to other routers and its attached prefixes. It is similar to an OSPF LSU containing one or more LSAs of different types.
Enter the NSX Giveaway – Tune In on LinkedIn
Do you remember the 21st night of September?
At VMware NSX, we sure do – and you can bet we’ll be dancing to Earth, Wind & Fire all September long. Whether or not this is your September song of choice, there’s no better way to listen to your favorite tunes than on a top-notch speaker. VMware NSX wants to help by giving away new portable Sonos Roam Speakers that you can bring wherever your grooving takes you.
Yep, you heard us – we’re hosting a giveaway! Entering for a chance to win is easy, too: just follow our new Networking & Security LinkedIn.
For an extra entry, tag a friend or colleague who would enjoy NSX content in the comments of the announcement post.
We’ll select winners from our new followers after the giveaway closes on Oct. 14, 2021. In the meantime, we’ll be listening to “September” on repeat. 
This giveaway is limited to those living in the US. If you live somewhere else you can still participate, but we may not be able to deliver your prize. See full Terms and Conditions below. If you have questions, reach out to us on LinkedIn or Twitter.
Full Stack Journey 058: New Challenges And Embracing Change
In episode 58 of the Full Stack Podcast, Scott talks to Nick Korte about a change that happened with his own podcast, The Nerd Journey. What lessons did Nick learn from this change, and how can those lessons be applied to careers in general? Scott and Nick's conversation uncovers some true gems of career advice.
The post Full Stack Journey 058: New Challenges And Embracing Change appeared first on Packet Pushers.
Full Stack Journey 058: New Challenges And Embracing Change
In episode 58 of the Full Stack Podcast, Scott talks to Nick Korte about a change that happened with his own podcast, The Nerd Journey. What lessons did Nick learn from this change, and how can those lessons be applied to careers in general? Scott and Nick's conversation uncovers some true gems of career advice.
The Top Network Upgrades You Should Consider Today
Network technologies and threats are advancing rapidly. Don't let your organization fall behind the times.Thoughts on the Collapsed Spine
One of the designs I’ve been encountering a lot of recently is a “collapsed spine” data center network, as shown in the illustration below.
In this design, and B are spine routers, while C-F are top of rack switches. The terminology is important here, because C-F are just switches—they don’t route packets. When G sends a packet to H, the packet is switched by C to A, which then routes the packet towards F, which then switches the packet towards H. C and F do not perform an IP lookup, just a MAC address lookup. A and B are responsible for setting the correct next hop MAC address to forward packets through F to H.
What are the positive aspects of this design? Primarily that all processing is handled on the two spine routers—the top of rack switches don’t need to keep any sort of routing table, nor do any IP lookups. This means you can use very inexpensive devices for your ToR. In brownfield deployments, so long as the existing ToR devices can switch based on MAC addresses, existing hardware can be used.
This design also centralizes almost all aspects of network configuration and management on the spine routers. Continue reading
AWS Networking – Part V: Create Subnet Using AWS Console
When we have created a new VPC, we can start adding subnets to it. We are going to create two subnets. Subnet 10.10.0.0/24 is a Public Subnet in Availability Zone eu-west2c, where we later add an Internet GW. Subnet 10.10.0.0/24 is a Private Subnet in Availability Zone eu-west2a that will use a NAT GW for uni-directional Internet access.
Figure 1-18: VPC Route Table: Routes.
Continue reading
AWS Networking – Part IV: Create VPC Using the AWZ CloudFormation
The focus of this section is to show how we can create a VPC using AWS CloudFormation service. Figure 1-12 shows our example AWS CloudFormation Templates. Its first section, AWSTemplateFormatVersion, specifies the template language format. At the time of writing, 2010-09-09 is the latest and only valid version. We can use the Description section to describe our template. Note that it must follow the AWSTemplateFormatVersion Section. AWSTemplateFormation-Version and Description are optional sections. The Resourcessection specifies the actual AWS resources and their properties. Each AWS resource is identified with a logical name. I have given the logical name NwktVPC for our example VPC. We can use resource-specific logical names for defining dependencies between resources. For example, when adding the AWS::EC2::Subnet resource to our template, we assign the VpcId value by calling it from the AWS::EC2::VPC resource using !REF intrinsinc function. I will explain the process in the Subnet section later. The resources and their properties are defined under logical names. The Resources section is the only required section in AWS CloudFormation-Template. AWS CloudFormation Templates are identified by using Stack Names in AWS Cloud Formation. Our example Stack Name is MyNetworkStack.
Figure 1-12: AWS CloudFormation: VPC.
Continue reading
Another SD-WAN Security SNAFU: SQL Injections in Cisco SD-WAN Admin Interface
Christoph Jaggi sent me a link to an interesting article describing security vulnerabilities pentesters found in Cisco SD-WAN admin/management code.
I’m positive the bugs have been fixed in the meantime, but what riled me most was the root cause: Little Bobby Tables (aka SQL injection) dropped by. Come on, it’s 2021, SD-WAN is supposed to be about building secure replacements for MPLS/VPN networks, and they couldn’t get someone who could write SQL-injection-safe code (the top web application security risk)?