Managing Security in a Microservices Architecture World

Micro Services architecture has become an increasingly popular method for building and deploying
software applications, offering a range of benefits such as increased agility, scalability, and efficiency. However, with the increased complexity of Micro Service Architecture comes new security challenges that organisations must address.

In this post, we'll explore some of the key security challenges of Micro Service Architecture and how DevSecOps can help organisations to effectively manage security in this environment.

Security Challenges of Micro Service Architecture

Increased complexity: One of the biggest challenges of Micro Services architecture is the increased complexity of the system. With multiple, interconnected Micro Services, it can be difficult to understand how security vulnerabilities in one service can impact the security of the entire system.

Configuration management: Another challenge of Micro Service Architecture is ensuring that each service is configured securely. With many services to manage, organisations must have a robust and consistent configuration management process in place to ensure that services are configured securely and consistently.

Lack of visibility: Micro Service Architecture can also make it difficult to see the big picture and understand the security posture of the entire system. With many services and components, it can be difficult to get a comprehensive view of the system's security status.

Coordination between teams: Another challenge of Micro Services architecture is coordinating security efforts between teams. With multiple teams working on different services, it can be difficult to ensure that security practices are consistent across the entire system.

Addressing the Security Challenges of Micro Service Architecture

Automated security testing: Automated security testing is a critical component of DevSecOps, and it can help organisations to identify security vulnerabilities in Micro Services architecture more quickly and efficiently. Automated security testing tools can be used to test the security of individual services and the entire system, providing organisations with a comprehensive view of their security posture.

Security-focused collaboration: DevSecOps encourages collaboration between development and security teams, which can help organisations to better coordinate their security efforts and ensure that security practices are consistent across the entire system

Continuous integration and deployment: Continuous integration and deployment (CI/CD) is a key principle of DevSecOps, and it can help organisations to ensure that security practices are integrated into the development process and that security issues are addressed quickly and efficiently.

Centralised security management: DevSecOps can also help organisations to centralise their security management processes, making it easier to manage security in Micro Service Architecture and ensuring that security practices are consistent across the entire system.

Wrap Up!

The security challenges of Micro Service Architecture can be daunting, but DevSecOps can help organisations to effectively manage security in this environment. By automating security testing, fostering collaboration between development and security teams, integrating security into the development process, and centralising security management processes, organisations can build a secure and stable Micro Service Architecture that protects against threats and vulnerabilities.

Azure Primer - Setting up the Network Layer

Azure isn't a platform I play with regularly, I can't say it's offering is one of my favourite but it has come a long way and does deserve some representation.

In this tutorial, we are going to play with Terraform, it's a familiar staple of this blog and requires not much explanation. It also allows us to put off the subject of ARTs within Azure as well. This guide does not include the use of variables which we should do in profession circumstances.

Before we get started, make sure you have the following prerequisites:

• An Azure account set up and you are logged in to the Azure portal.
• Terraform installed on your local machine.

As always Configuration File!

The first step in setting up a network on Azure using Terraform is to create a configuration file. This file will contain the code that defines the resources you want to create on Azure.

To create a configuration file, open your favourite text editor and create a new file called main.tf.

At the top of the file, define the provider for Azure:

provider "azurerm" {
  version = "=2.34.0"
  subscription_id = "your-subscription-id"
  tenant_id = "your-tenant-id"
}

Replace "your-subscription-id" and "your-tenant-id" with the appropriate values for your Azure account.

The Virtual Network

The next step is to create a virtual network, or VNet, using Terraform. A VNet is a representation of your own network in the cloud. It enables you to securely connect Azure resources to each other, as well as to on-premises networks.

To create a VNet with Terraform, add the following code to your configuration file:

resource "azurerm_virtual_network" "example" {
  name                = "example-vnet"
  resource_group_name = "example-resource-group"
  location            = "westus2"
  address_space       = ["10.0.0.0/16"]
}

This code creates a VNet called "example-vnet" in the "westus2" region and assigns it an address space of 10.0.0.0/16.

Creating the Subnets!

Now that you have created a VNet, the next step is to create one or more subnets within it. A subnet is a range of IP addresses within a VNet that you can use to group Azure resources.

To create a subnet with Terraform, add the following code to your configuration file:

resource "azurerm_subnet" "example" {
  name                 = "example-subnet"
  resource_group_name  = "example-resource-group"
  virtual_network_name = azurerm_virtual_network.example.name
  address_prefix       = "10.0.1.0/24"
}

This code creates a subnet called "example-subnet" within the "example-vnet" VNet and assigns it an address prefix of 10.0.1.0/24.

Configure your Network Security Groups

A network security group (NSG) is a layer of protection for your Azure network that allows you to control inbound and outbound traffic to and from your resources. You can create NSGs at the subnet level or at the individual resource level.

To create an NSG with Terraform, add the following code to your configuration file:

resource "azurerm_network_security_group" "example" {
  name                = "example-nsg"
  resource_group_name = "example-resource-group"
  location            = "westus2"
}

This code creates an NSG called "example-nsg" in the "example-resource-group" resource group in the "westus2" region.

Once your NSG is created, you can add rules to it to control the traffic to and from your resources. To do this, add the following code to your configuration file:

resource "azurerm_network_security_rule" "example" {
  name                        = "example-rule"
  resource_group_name         = "example-resource-group"
  network_security_group_name  = azurerm_network_security_group.example.name
  priority                    = 100
  direction                   = "Inbound"
  access                      = "Allow"
  protocol                    = "Tcp"
  source_port_range           = "*"
  destination_port_range      = "80"
  source_address_prefix       = "*"
  destination_address_prefix  = "*"
}

This code creates an inbound rule that allows TCP traffic on port 80 from any source to any destination.

Deploy ALL Resources

Now that you have defined all the resources you want to create on Azure, the final step is to deploy them. To do this, run the following command from the command line:

terraform apply

This will create all the resources defined in your configuration file on Azure.

Wrap Up!

In this tutorial, we showed you how to set up a network on the Azure Cloud Platform using Terraform. We walked through the steps of creating a VNet, subnets, and NSGs, and demonstrated how to configure these resources to meet your specific needs. We hope this tutorial was helpful and gives you a good starting point for building and managing networks on Azure using Terraform.

Home Vs Away: Network differences

There are key differences between home and enterprise networks.

This article offers a description of the differences between home and enterprise Wi-Fi. When deploying a Wi-Fi network, enterprises can benefit from carefully considering the choice of devices and cloud management network platforms that can deliver the features and reliable service needed for stable wireless networks. Enterprises can discover new business opportunities by exploring data value from wireless networks.

With the popularity of smartphones, everyone has become used to accessing Wi-Fi networks anytime, anywhere. Because Wireless LAN (WLAN) access is easy and transparent, Wi-Fi devices for a company, shopping mall, or hotel seem to work the same as home Wi-Fi. These Wi-Fi devices differ in significant ways, however, and the differences are important to understand when setting up enterprise Wi-Fi networks. This article looks at the differences between home and commercial Wi-Fi

Price is another difference. A home Wi-Fi router costs tens to hundreds of dollars, while a commercial AP costs hundreds or thousands of dollars. The reason for the price difference lies in the AP’s many advanced features, beginning with the interface ports.

Security is important in a business setting.

Needs Firewall & antivirus software: The data is transferred on the internet which can be changed or hacked by the hackers, so the firewall needs to be used. Some people can inject the virus in our system so antivirus is needed to protect from such a virus.

Whenever possible, you should connect to a security-enabled wireless network. If you do connect to a network that's not secure, someone with the right tools can see everything that you do, including the websites you visit, the documents you work on, and the user names and passwords that you use.

Sometimes (to tell the truth, very often) it is necessary to make it look like both the client and the server are in one private network. For example, when all the company services are in private network, which is accessible only from the office, but you need to give a remote access to the company workers. Or when a company has several offices or data centres, which need to be connected with each other in such a way that all the network still would not be accessible to all Internet.

Businesses should consider open source and closed source software options.

Additionally, your choice will also depend on the needs and requirements of your business. Does the usefulness of a system which is completely free of cost, outweigh the running costs, security risks and lack of support that comes with it? If so, then it would be in your interest to join the growing trend of open-source software.

Looking for software for their companies business owners often face a difficult choice between closed source and open source software. The thing is that the choice is not always obvious, as each of the software has its particularities with a mix of advantages and disadvantages.

– Service: Closed source software is the winner here, as there are usually dedicated service teams that can help you when things go wrong. If you’re using open source software though, you’ll be at the mercy of the online community, who may not be incentivised to help you.

DHCP, wi-fi, and cables are important in an enterprise setting.

Ethernet router (only needed if you want to connect more than two devices that share an Internet connection)A router helps you share a single Internet connection among several devices. You don't require a router to set up a wired network, but you should use one if you want multiple devices to share an Internet connection.

To make your machine communicate with other machines and other networks, routing information must be given to make network traffic take the correct path. If DHCP is used, this information is automatically provided. If a static setup is used, this data must be added manually.

Wireless devices should connect to the network infrastructure securely where possible. In an enterprise environment, secure the WLANs by configuring at least WPA2 with AES-CCMP encryption, and 802.1x authentication of devices. This is sometimes referred to as WPA Enterprise on wireless devices. Most modern wireless devices support WPA2. You should consider migrating to the newer WPA3 standard, which is supported by Cisco Catalyst 9800 Series wireless controllers.

Screen vs tmux

...Yet Another Comparison guide

Recently, at work this subject came up again... Whether or not I was fanning the flame war is another matter. Hilariously, much like an old article I had written before and again recently found (recorded below) "the war" had begun the same, an engineer had just discovered Screen...

I always love causing joining in a good flame war, regardless of the technology. I am a proud member of the church of Vi! For Example.. The reason being as it helps us to learn and challenge the way that we do things, I have learnt more about technology from heated discussions with passionate people that I have ever learned from a README.md file! In many ways I believe these discussions are necessary for a healthy development environment!

Opinions from the past

In terms of functionality not much has actually changed under the hood for both of these candidates, they both essentially do the same thing they have done for years. In many ways, they shouldn't change as testament to what was created.

Here is the post I wrote oh so many, many years ago when I was younger and more naive, or was I?

GNU Screen and tmux are terminal multiplexers designed for Unix-like platforms. They are basically window managers for text consoles instead of the X Window System. Screen is the more heard-of terminal multiplexer.

tmux-only features include:

• Client/server system - a server instance is started automatically when a session runs as a client for that server, which leaves less of a footprint.
• Synchronize-panes - duplicate input from any pane to all other panes in the same window. A bit like a clusterssh function to simultaneous input to all of the terms all at the same time.
  ctrl+b :set-window-option synchronize-panes [on|off]

Screen only features include:

• Zmodem transfers - the abilty to transfer files when all you have is a serial connection available. Although this sysadmin does not need to use this feature.
• Attaching to a serial tty - such as screen -r /dev/ttyS0 115200 in case you lose a session.
• Naming of invidual panes - you can name each pane in case you loose track of things! TMUX wins for me

I first started using Screen, but I quickly found tmux to be the better option. With less of a footprint to deal with, I could have many hands on one server with out the need to keep spawning servers. I also found tmux had a better mastery of panes (as a terminator user very important!) and the conversion from Screen was simple after getting used to using ctrl+b instead of ctrl+a.

 

Back to the present war

This would continue as (regardless of the multiplexer they mentioned... I would have probably picked the opposite side) I would begin to argue a lot of the above points about TMUX over screen. There would be some back and forth banter about Key Bindings, much like the above article, finally a few days later the OP would return to the thread and agree...

In my humble opinion this just cements that TMUX is still the better option!!

Verdict!

It would appear that nearly a decade later, I am still correct in my promotion of the far superior TMUX. Out of the box it is noticeably more colourful, despite the key bindings being different to Screen that for some reason newbies find easier to pick up, most are willing to make the jump for the extra screen bling.

Of course if screen bling is you goal might I suggest:

$ fortune | cowsay | lolcat # add to a while loop for some pretty and informational graphics!