Hey everyone, hoping someone here has run into this and found a solution. We've been integrating Netskope for our cloud security posture, and overall it's been solid. But we've hit a snag that's really slowing down development.
Our CI/CD pipelines (mostly GitHub Actions, some Jenkins) are suddenly getting flagged. Specifically, traffic from our build agents to `api.github.com` and `objects.githubusercontent.com` is being categorized as 'High Risk' and sometimes blocked. This is breaking package pulls, repo checkouts, you name it. It seems Netskope is interpreting the automated, high-volume traffic from our known CI/CD IP ranges as suspicious.
I've checked the admin console, and I see the alerts piling up under the "Cloud Analytics" section. The activity is tagged as `Cloud Service - High Risk`. We need to get these whitelisted, but I want to make sure we do it in the most secure, precise way possible. I don't want to just blanket-allow all traffic to GitHub.
Has anyone crafted a precise policy for this? I'm thinking it involves:
1. Creating a private app instance for our CI/CD traffic?
2. Defining a source IP list (our CI/CD static IPs).
3. Creating an allow policy for that source to the specific GitHub SaaS instances.
But the devil's in the details. What's the best practice here? Should we use a **Secure Forwarder** configuration on the agents, or is a simple **Client Connector** with a specific policy profile enough? Our infra is mostly containerized, so we're also considering if we need a Docker-based forwarder in the pipeline itself.
Here's a snippet of the kind of traffic we're seeing blocked, from a pipeline log:
```bash
fatal: unable to access 'https://github.com/our-org/our-repo.git/': Netskope: Connection timed out
```
Any concrete examples of policy JSON or the exact steps in the UI would be a huge help. I want to test this in our staging Netskope tenant before rolling it out.
Thanks in advance for any pointers!
~d
Your approach with the source IP list is the right start, but have you verified your CI/CD IPs are truly static? GitHub Actions runners can be ephemeral, depending on your setup. You might be chasing a moving target.
Creating a private app instance in Netskope for this traffic could give you more granular control than a broad allow policy. It lets you treat the CI/CD service as a known entity.
What about the risk of whitelisting `objects.githubusercontent.com`? That's a huge CDN. Could you scope the policy to specific, known repository patterns instead?