Inject Authorization Header with Apigee Proxy
I will answer the second question in item 3 - “This requires us to stand up an intermediate proxy collector to inject Authorization?”
Yes, you can create a Trace helper proxy in Apigee that could inject the Authorization header into the Splunk request. You can also include an API key in the query parameter of the traceConfig. I’ll outline three high-level things that you can do to secure the Apigee proxy below.
- Deploy the proxy to an environment that is only accessible from within your VPC network.
- Include an Access Control policy in the request preflow to validate the request is from an internal/external IP address.
- Include a Verify API Key policy in the proxy and pass the API Key in the traceConfig payload as a query parameter (see example below).
Secure the Trace Helper proxy
Create an Apigee proxy that includes a Verify API policy in the request preflow. You can pass an API key in a query parameter in the Jaeger traceConfig request payload as shown below.
"endpoint": "https://api.exco.com/jaeger?apikey=some-unique-key"
Allow Internal Requests
You can use this approach if you want your Trace helper proxy to receive requests from within your network only.
- Create an internal only Application Load Balancer (ALB).
- Use Cloud DNS to register a domain name to the Internal ALB’s private IP address.
- Create an Apigee Environment and Environment Group that has the ALB’s hostname.
- Add an Access Control policy in Apigee Trace helper proxy and include the Allow Action to allow IP Ranges from your Apigee VPC Peering range.
Allow External Requests
- Configure Apigee NAT addresses for Apigee runtime instances.
- Configure Access Control policy to Allow Apigee NAT IP addresses and Deny all other IPs.
Your API Traffic will Increase
If you decide to use an Apigee proxy, then that will increase your API call volume. Cloud Trace allows you to configure a probability sampler between .1 and .5, which means that the Distributed Tracing will randomly select a request and send that to your Trace tool. The sample rate and the amount of time Distributed Tracing is running will determine how much your API traffic will increase.
For example, if you enter .5 or 50%, then Distributed Tracing will randomly select 50% of your API traffic and send it to your Trace helper proxy. If you send 1M requests, then 50% of those requests will be sent to your Trace helper proxy, bringing your total API volume to 1.5M requests. If you are ok with increasing your API volume in Apigee, then this is the best approach. Alternatively, you could accomplish your goal of injecting the Auth header without an Apigee proxy by writing custom code and deploying it within Cloud Run or a Cloud Function.
Missing Span IDs
I copied and pasted the documentation that we have regarding the missing span IDs. This might be the reason why you see Missing Span ID in your distributed tracing tool.
“In distributed tracing systems, incomplete traces are expected. A trace is incomplete when a sampled span contains a reference to another span that hasn’t been received. The unresolved reference can occur for the following reasons:
- The referenced span wasn’t sampled.
- The referenced span was sampled but hasn’t yet been received by Cloud Trace or the span was received but not stored.”
See this documentation link for more information.
https://cloud.google.com/trace/docs/troubleshooting#missing-span-id
Thanks @kurtkanaskie for your help on reviewing this.