Gitlab-Runner causing RackAttack and being blacklisted

Summary

Registering a gitlab-runner is causing IP to be blacklisted for rack attack.

Steps to reproduce

Follow the instructions to create a gitlab-multi-runner, set up as shell runner. Wait awhile and I am blacklisted. This is happening to me on gitlab.com with a runner I setup, also with a different runner I setup on AWS.

Next I tried community edition with from scratch on AWS with a runner and the same issue happened.

What is the current bug behavior?

I'm unsure if it's something with my build is doing (I can post my gitlab-ci.yml file if you think this is it), but after awhile I get blacklisted and can no longer visit or run builds for my gitlab repos from whatever IP was blacklisted.

What is the expected correct behavior?

Not to be blacklisted

Relevant logs and/or screenshots

A couple lines from production.log from the new gitlab ci instance I just booted up.

Rack_Attack: blacklist <myip> GET /jwt/auth?account=gitlab-ci-token&scope=re
pository%3Aots%2dashboard%3Apull&service=container_registry
Started GET "/jwt/auth?account=gitlab-ci-token&scope=repository%3Aots%2Fdashboard%3Apull&service=container_registry" for <myip> at 2017-02-13 00:13:52 +0000
Rack_Attack: blacklist <myip> GET /jwt/auth?account=gitlab-ci-token&scope=repository%3Aots%2Fdashboard%3Apull&service=container_registry
Started POST "/ci/api/v1/builds/register.json" for <ip> at 2017-02-13 0

Output of checks

This bug happens on Gitlab.com

Possible fixes

I'm not sure if there is some setup that isn't property documented that I'm missing, or if these runners are for some reason pinging/logging into gitlab too often to trigger this as an attack, If the runners are polling for new jobs or something though I would think these would be exempt from the attacking rules in place.