Using Apickli to integration test northbound IP Whitelisting.

[davissean]

I have implemented an Access Control policy in an Edge proxy, to implement northbound IP whitelisting for a given client. Requests may be triggered by the client or by integration tests run by CI or developer's machines. In order to integration test this...

Options:

1) Skip Access Control policy when running integration tests - this isn't ideal as the policy is then untested.

2) Skip Access Control policy for integration tests AND manually test from the client - this isn't in the spirit of CI as the test overhead increases per release.

3) IP spoofing - it may be possible to spoof IP addresses using the nodejs request library in Apickli.

4) Also add CI IP address to the policy and skip these tests from developers machines - this may be an issue if IP address are not static for CI tools like Codeship. In this case, you would have to add an entire EC2 region (https://community.codeship.com/t/add-codeship-into-ip-whitelist/723)

5) It could be argued that Access Control policies should already be tested by the Apigee platform, and are more of a configuration policy. In this case, it may be valid to skip this testing.

Any thoughts?

[ozanseymen · Accepted solution]

Hi @Sean Davis

I think it is important to test the configuration of Access Control policy as if I make a wrong configuration, proxy might fail to deploy or worse, all requests from legitimate clients may be blocked.

As you know Access Control policy looks at X-Forwarded-For header. There is an additional configuration option for this policy, called "ValidateBasedOn" which can be used to control which IP in the chain to use for validation.

My recommendation is:

1. Set this property to X_FORWARDED_FOR_ALL_IP - which is a best practice in my opinion (and it is the default setting for this property). That will look at all IPs in the chain and make sure all IPs in X-Forwarded-For are valid. Otherwise I can hide my nasty app behind a web proxy and bypass your controls.
2. In your integration tests (dev machines or CI, etc) explicitly set the X-Forwarded-For header (on the test request) to contain one or more IPs in the control list. In effect what this would say is "I am forwarding this request on behalf of someone else". There are 4 combinations to test:
   1. All IPs valid
   2. All IPs invalid
   3. One IP in 1+ IP list is invalid
   4. Multiple IPs in 3+ IP list is invalid

The only combination you will never be able to test is "last IP in the chain is invalid" - because you won't be able to set your invalid IP in X-Forwarded-For header. There you will have to trust Apigee Engineering to test that condition in policy's unit tests.

[ozanseymen]

Also see this for a discussion around X-Forwarded-For header tricks: https://community.apigee.com/comments/28887/view.html

[nmunro]

Hi @Sean Davis,

While this isn't the answer to your question, I thought about the following for Option 4 where the IP address of the Codeship build machine is not known in advance.

I tried using a Maven plugin to get the host IP address http://www.mojohaus.org/build-helper-maven-plugin/usage.html

According to the link above this is titled "Retrieve current host IP address"

 <plugin>
 	<groupId>org.codehaus.mojo</groupId>
        <artifactId>build-helper-maven-plugin</artifactId>
        <version>1.11</version>
        <executions>
        	<execution>
                        <phase>initialize</phase>
                        <id>get-local-ip</id>
                        <goals>
                            <goal>local-ip</goal>
                        </goals>
                        <configuration>
                            <!-- if not given, 'local.ip' name is used -->
                            <localIpProperty>my.local.ip</localIpProperty>
                        </configuration>
                </execution>
        </executions>
</plugin>
	

and then setting the AC policy with the property:

<AccessControl name="AccessControlPolicy.CI">
  <IPRules noRuleMatchAction="DENY">
    <MatchRule action="ALLOW">
      <SourceAddress mask="16">${my.local.ip}</SourceAddress>
    </MatchRule>
  </IPRules>
</AccessControl>

For Maven executed locally, the IP address added to the policy seemed to be different from the IP address used for the tests and the AC policy locked me out.

Similarly, tracing a request from Postman confirmed this with X-Forwarded-For being very different from the IP set on the policy.

When attempting to use it in a Codeship build, Codeship returned localhost (127.0.0.1) as the IP address - clearly this isn't going to work either.