How to restrict a route access for IP addresses?

[ShaonDey]

Specifications

TargetFramework: net6.0
Ocelot Version: 17.0.0

Description

Is there any feature to restrict a route so that only specific IP addresses will be able to access it?

[ggnaegi]

[ShaonDey]

Yes @ggnaegi, adding a custom handler can be a way to achieve this.
But I was hoping whether Ocelot has any built one.
IMO, API Gateway should have these kinds of features in it.

[ggnaegi]

@ShaonDey I deleted my post, since @raman-m just gave you the correct answer: #1735 (comment)
So, yarp doesn't offer any built-in IP-White/Blacklisting feature, but ocelot does 😄
I haven't used it myself, therefore the mistake.

[raman-m]

@ggnaegi replied

Gui, don't do that! You've got official warning! 🟥 You know for what...

Shaon doesn't need even to compare to other gateway products because we have nice Security Options feature in Ocelot Route configuration! ⚠️ See my final answer.
So, using a delegating handler life hack is not required because we have Security Options feature.
Thanks, for being proactive!

[raman-m]

Hi Shaon!

TargetFramework: net6.0
Ocelot Version: 17.0.0

Actually you're using Ocelot v18.0 if your target framework is net6.0, because we have only one .NET 6 release and this is Ocelot 18.0.0:

.NET 6 release history in Git

If you use Ocelot v17.0.0 then target framework is net5.0, see release 17.0.* and NuGet Ocelot 17.0.1

You should be more specific in providing version information. 😉

[ShaonDey]

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net6.0</TargetFramework>
    <DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Microsoft.VisualStudio.Azure.Containers.Tools.Targets" Version="1.17.0" />
    <PackageReference Include="NLog" Version="5.0.0-preview.3" />
    <PackageReference Include="Ocelot" Version="17.0.0" />
  </ItemGroup>

</Project>

Hi @raman-m, My project is running with the above-mentioned framework & package versions. I think I need to update the project. THOUGH with the above-mentioned specification, it is working as expected!

[raman-m]

Yes, you need! See my final answer please! And, please mark my reply as answered.

[raman-m]

Is there any feature to restrict a route so that only specific IP addresses will be able to access it?

@ShaonDey

net6.0

You need to use SecurityOptions of the route configuration. This is undocumented feature because the authors were lazy in describing this feature in docs. 😏 See Security Options history! So, basic support of Security Options was added in this commit 4a8f4c2. And this feature belongs to versions 12.0.1+, so the security feature belongs to Ocelot 17.0.0+, but it is not documented. 🙉

net7.0

In release 20.0 the Security Options feature was enhanced in PR #1399 by commit 5dbbbef:

• #1400 Manage multiple patterns for allowed/blocked IPs via Security Options config section #1399
• Manage multiple patterns for allowed/blocked IPs via Security Options config section #1400

The Security Options feature is documented in .rst-files already, but we have no ReadTheDocs build because of failure, and we are going to fix build problem soon in release 20.0 by making new 20.0.1 release in 1-2 days. Please watch for a new release!

Finally,

I would recommend you to migrate your solution to .NET 7 vs Ocelot v20.0 to use the Security Options feature. You will be able to restrict access for a route by a black list creation via the IPBlockedList array property in JSON. See more details in commit 5dbbbef plz.
If the migration to .NET 7 is impossible now, you are still able to restrict access for .NET 6. See above!
Enjoy! 🎉

[ShaonDey]

"SecurityOptions": {
  "IPBlockedList": [],
  "IPAllowedList": ["10.0.0.0"],
  "ExcludeAllowedFromBlocked": true
}

@raman-m, A quick question, with the above-mentioned configuration will it only allow requests from the "10.0.0.0" IP address?

[raman-m]

Yes, 10.0.0.0 is one IP address! If you'd like to define a range then go with 10.0.0.X-Y syntax.
More details on IP definitions in docs of IPAddressRange project on GitHub: Example
Hope it helps!

[ShaonDey]

<Project Sdk="Microsoft.NET.Sdk.Web">
	<PropertyGroup>
		<TargetFramework>net6.0</TargetFramework>
		<DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
	</PropertyGroup>
	<ItemGroup>
		<PackageReference Include="Ocelot" Version="18.0.0" />
	</ItemGroup>
</Project>

SO, as per my testing on the SecurityOptions feature, I have found out that with the above-mentioned specification, both the IPBlockedList & IPAllowedList allow a list of a string consisting of ONLY Static IP Address values. It does NOT support any kind of syntax/range. And the Ocelot configuration goes like so:

{
  "Routes": [
    {
      "DownstreamPathTemplate": "/todos/{id}",
      "DownstreamScheme": "https",
      "DownstreamHostAndPorts": [
        {
          "Host": "jsonplaceholder.typicode.com",
          "Port": 443
        }
      ],
      "UpstreamPathTemplate": "/posts/{id}",
      "UpstreamHttpMethod": [
        "Get"
      ],
      "SecurityOptions": {
        "IPBlockedList": [ "10.0.0.1", "20.0.0.1" ],
        "IPAllowedList": [ "30.0.0.1", "40.0.0.1" ],
        "ExcludeAllowedFromBlocked": true
      }
    }
  ],
  "GlobalConfiguration": {
    "BaseUrl": "https://localhost:5000"
  }
}

Voilà! It works as expected.

If I migrate my project's to .NET 7along withOcelot="20.0.0"` it then should support syntax/range along with the others mentioned on the dependent package. Though I haven't gotten the chance to test this as I then have to migrate my existing project.

[raman-m]

@ShaonDey I have no idea how the feature behaves in .NET 6 and Ocelot v18 environment where there is the old version of the feature, and it requires local tests.
I strongly recommend you to migrate to .NET 7 and Ocelot v20, thus you will be able to use full power of library IP syntax, including short range syntax like 192.168.10.X-Y
And if you're going to define all addresses of 10.* private network you'll need to define a range 10.0.0.0-10.255.255.255.
Hope it helps!

Also, I do not recommend to block/allow so large networks like from "10.0.0.1" to "20.0.0.1" because it will produce 16 millions of items in memory, and, it seems, Ocelot will have low performance. So, we have a design issue in Security Options for large networks. Ocelot will consume significant memory blocks, and I will open issue soon. I found and realized the issue right today.
I recommend to define IP ranges of small networks like 10.0.0.X-10.0.0.Y.
If you would like to manage access for private networks, I recommend you to deploy web server and Ocelot app inside of this private network, thus you don't need to manage IPs via security at all.
If Ocelot will be deployed to public web server then there is no sense to block global IPs, but sure you can restrict access for specific IPs of your clients which communicate by global IPs.

[raman-m]

@ggnaegi The problem with Security Options feature design is above!

[raman-m]

@ShaonDey Don't you mind if your question will be pinned for a couple of future releases? But you're free to mark as answered.
We have strange undocumented feature incident by previous contributors because of the lack of project management, explained in final answer, and I believe the Ocelot community will express high interest in using of Security Options feature.

[ShaonDey]

@raman-m, Please do so! I don't mind.
Meanwhile, I'll be testing the SecurityOptions feature and inform here. Hope this will help others as well.

[raman-m]

You needn't enable SecurityMiddleware explicitly because the middleware is already built-in to Ocelot pipeline. Just start writing security options in route JSON.

That will be awesome if you provide a feedback in future how this feature works in production environment.
Is it stable? Which logs does it produce? Performance, and etc.
I expect a lot of log records because of generating errors in IPSecurityPolicy class. It seems request status code is overridden because of UnauthenticatedError objects.

And, good luck in your endeavors with Ocelot! 🐈‍⬛ 🐅
Come back to us with new PRs if you have time to contribute! 😉