While connecting to your MongoDB deployment is necessary, it's equally important to control who can establish these connections. Setting up authentication and authorization provides a good security foundation, but effective security requires multiple layers of protection. One additional layer we can implement is restricting which IP addresses can access our MongoDB deployment. In this lesson, we'll explore what IP binding is and how we can configure it in a MongoDB deployment. Let's begin. The public Internet connects billions of devices worldwide, creating an interconnected network that allows information to flow freely. While this connectivity brings tremendous benefits, it also introduces security challenges. Leaving your MongoDB deployment accessible to the entire public Internet creates a significant security risk. Even with authentication enabled, your system still needs to process connection attempts from unauthorized sources, potentially exposing it to brute force attacks or yet undiscovered vulnerabilities. Each connection attempt to your database represents a potential entry point. Without proper controls, your data might be a risk of unauthorized access, modification, or even deletion. This is why limiting access to your MongoDB deployment is so important. For many organizations, data protection isn't just good practice, it's a legal requirement. Various regulations like GDPR, HIPAA, and others mandate specific security controls for different types of data. Controlling who can connect to your database is often a core requirement of these regulations. By implementing IP binding, we can restrict which IP addresses can even attempt to communicate with our MongoDB instance. This works hand in hand with firewall rules to create multiple layers of protection. IP binding acts as a first layer of defense by restricting access to specific IP addresses. On the other hand, firewalls act as a broader security mechanism at the network level, protecting against unauthorized access and traffic across the entire network infrastructure. For example, you can configure your firewall to restrict the MongoDB traffic to only accept connections from accesslisted client IP addresses. Firewall configuration is both a science and an art. We'll explore more advanced configuration and best practices in the next video. In this video, we'll focus specifically on configuring IP binding within your MongoD configuration file. Let's get started. Within the net section of the MongoD configuration file, the port and bindIP fields define the IP address and port where MongoDB listens for incoming connections. By default, MongoDB only listens on port 27017 and IP address 127.0.0.1, Meaning, it only accepts connections from the same machine where it's running. This default prevents all remote access. Let's change that. MongoDB's IP binding system supports both IPv4 and IPv6 addresses, giving you flexibility in how you define your network architecture. You can specify addresses in several formats, IPv4, IPv6, DNS host names that resolve to either IPv4 or IPv6, or UNIX domain socket paths for local connections. When configuring production systems, we recommend using DNS host names rather than hard coded IP addresses. This provides more flexibility since IP addresses can change, while your host name can remain consistent. Using host names is especially important for replica sets and sharded clusters, where MongoDB nodes need reliable ways to find each other. If you need to specify multiple addresses, you can do so by separating them with commas. For example, this configuration would allow connections from the local machine, the specific IP address 192.168.1.10, and whatever IP address the host name, mongodb.example.com, resolves to. If you need to allow connections from any IP address, you can use 0.0.0.0 for all IPv4 addresses, or you can use the bindIpAll setting instead. However, this approach is generally not recommended for production environments. Opening your database to all incoming connections significantly increases your security risk, especially if exposed to the public Internet. Keep in mind that when you use bindIpAll, it's mutually exclusive with bindIp. You can use one or the other, but not both in the same configuration. Another secure approach for remote MongoDB access is using a virtual private network or VPN. A VPN establishes an encrypted connection over the Internet between your device and a remote server, creating a secure tunnel that prevents your data and online activity from being exposed to the public network. When using a VPN, devices receive private IP addresses that aren't routable on the public Internet. With this setup, you can configure your MongoDB instance to listen on its private VPN address. This configuration allows MongoDB to accept connections from the local machine and any device that has VPN access to the specified private IP address. The primary benefit is security through isolation. Your MongoDB deployment remains completely hidden from the public Internet while still allowing remote connections through the VPN secure channel. For this to work effectively, both your MongoDB server and any connecting clients must be properly configured within the VPN network. Once you've updated your MongoDB configuration file with the appropriate IP binding settings, you'll need to restart your MongoDB instance for the changes to take effect. Keep in mind that if your deployment is using a replica set, you can perform a rolling restart to avoid downtime. Restart one node at a time starting with the secondary nodes and verify each node rejoins the set before moving on to the next. Once complete, it's good practice to test connectivity from both allowed and restricted IP addresses to confirm that your IP binding settings are working as expected. Connections from unauthorized IP addresses should be rejected with a connection error. Remember that IP binding is just one layer of your security strategy. While it restricts which machines can connect to your MongoDB instance, it doesn't authenticate users or encrypt data in transit. Consider combining IP binding with user authentication and authorization, TLS or SSL encryption for data in transit, and firewall rules as an additional network layer of protection. Great work. Let's take a moment to recap what we learned in this lesson. First, we learned that the public Internet connects billions of devices worldwide, creating an interconnected network that allows information to flow freely. We also learned that having a MongoDB instance open to all connections on the public web leaves us vulnerable to unauthorized access to our data. After that, we learn that IP binding allows us to control where machines are connecting to our MongoDB instance from. Once we learned about IP binding, we explored how we can configure it for ourselves. Finally, we applied our new settings by performing a rolling restart on our MongoDB deployment.