Allow proxy to accept local callouts only

Not applicable

I have Proxy1 that makes a LocalTargetConnection in ServiceCallout policy to my Proxy2. I wan't to disable external connections to Proxy2 so it can be accessed only by Proxy1. Is there a way to allow Proxy2 to be accessed only by Proxy1?

Solved Solved
1 6 861
1 ACCEPTED SOLUTION

adas
New Member

@MSaichuk

There are multiple ways to do this. You can use a verifyApiKey policy in your second proxy so that when you make service callouts from the first proxy you can pass the apikey but that would not be exposed to external folks so they won't be able to make calls to that proxy. The other option is to use an ACL policy and allow some arbitrary x-forwarded-for IP like 192.168.10.10 which can be passed internally by the service callout policy so you would restrict access to public network.

In the case of ACL policy, you can fake the x-forwarded-for header by using an assign message policy to create a request object for the service callout. Notice, that in both cases the proxy is still invokable from public network but you are restricting the policy execution by adding the ACL or VerifyAPIKey at the very beginning.

But I was thinking of another solution that allows you to complete safeguard against your internal proxy. Here's what I did,

I created a new virtualhost called "internal" with a hostAlias of internal.mydomain.com something that doesn't exist. Now I deployed my chained proxy on this virtualhost, which mean external folks would not be able to call this even if they know the basepath because that hostAlias is not known, nor does it exist. So now I can make calls to my proxy from a service callout using LocalTargetConnection but the same cannot be accessed from outside. I am attaching my sample proxies for the sake of understanding.

internal-v1-rev1-2016-06-17.zip

httpbin-rev1-2016-06-17.zip

My virtualhost config looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VirtualHost name="internal">
    <HostAliases>
        <HostAlias>internal.apigee.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9980</Port>
</VirtualHost>

This should be a complete solution for your usecase. Please let me know if this helps.

View solution in original post

6 REPLIES 6

Not applicable

Access Control Policy might help you.

Access Control Policy works with 'X-Forwarded-For' header value, but if request comes from Service Callout Policy - this value is undefined

@MSaichuk ,

A simple worked around can be,

  • Store a random 32 / 64 char string in a KVM
  • In Proxy 1 retrieve this KVM value & send it as a header value in API call to Proxy 2.
  • In Proxy 2 compare header value received with the value stored in KVM & allow access to proxy 2

adas
New Member

@MSaichuk

There are multiple ways to do this. You can use a verifyApiKey policy in your second proxy so that when you make service callouts from the first proxy you can pass the apikey but that would not be exposed to external folks so they won't be able to make calls to that proxy. The other option is to use an ACL policy and allow some arbitrary x-forwarded-for IP like 192.168.10.10 which can be passed internally by the service callout policy so you would restrict access to public network.

In the case of ACL policy, you can fake the x-forwarded-for header by using an assign message policy to create a request object for the service callout. Notice, that in both cases the proxy is still invokable from public network but you are restricting the policy execution by adding the ACL or VerifyAPIKey at the very beginning.

But I was thinking of another solution that allows you to complete safeguard against your internal proxy. Here's what I did,

I created a new virtualhost called "internal" with a hostAlias of internal.mydomain.com something that doesn't exist. Now I deployed my chained proxy on this virtualhost, which mean external folks would not be able to call this even if they know the basepath because that hostAlias is not known, nor does it exist. So now I can make calls to my proxy from a service callout using LocalTargetConnection but the same cannot be accessed from outside. I am attaching my sample proxies for the sake of understanding.

internal-v1-rev1-2016-06-17.zip

httpbin-rev1-2016-06-17.zip

My virtualhost config looks like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VirtualHost name="internal">
    <HostAliases>
        <HostAlias>internal.apigee.com</HostAlias>
    </HostAliases>
    <Interfaces/>
    <Port>9980</Port>
</VirtualHost>

This should be a complete solution for your usecase. Please let me know if this helps.

This works fine. The only thing I would like to mention: looks like ValidateBasedOn parameter of ACL policy is ignored and always validates first IP. If you set x-forwarded-for on external call - it will be the first IP in this header and actual IP assigned by apigee will be the second value after comma. If you perform callout from another proxy - x-forwarded-for is not appended by any value so it stays the same as you set by yourself. But no matter what ValidateBasedOn parameter I set - ACL policy seems to allways validate the first IP before comma.

adas
New Member

I actually wrote up an entire article on this: https://community.apigee.com/articles/26525/securing-your-internal-apis-with-apigee-edge.html

Hopefully this would give you some good insights about proxy exposure and restricting your internal APIs.