Java callout permission issues on Apigee Hybrid 1.8.5 on GKE Anthos 1.14.1

Hello,

Our java callout uses an http client to POST some data to external endpoint:

We are seeing the following permission issues:

("java.net.SocketPermission" "10.113.1.5:443" "connect,resolve")

I followed the instructions on https://cloud.google.com/apigee/docs/api-platform/develop/adding-custom-java-callout-security-policy and added the following policy:

 

 

 

 

grant {
    permission java.net.SocketPermission "10.113.156.32:443", "connect";
};

 

 

 

 

 Once that was uploaded and applied, we got a new permission error:

 

 

 

 

java.util.PropertyPermission" "java.version" "read"

 

 

 

 

Also, with the security policy applied, if we used a hostname to create a socket, we got a permission error for SocketPermission "resolve", even though according to the docs it should be permitted.

Looking at:
https://cloud.google.com/apigee/docs/api-platform/reference/java-permission-reference

I think socket connect and resolve should be allowed by default.
We have tested Hybrid on other deployments without having to provide the custom java policy.

My questions:

  1. Are the restrictions in Hybrid 1.8.5 different to the restrictions described in the documentation? (Specifically the security permissions)
  2. Should creating a socket to 10.113.165.31 be permitted?
  3. Once a custom java security policy is applied, does it replace the default security policy in apigee hybrid?  If so, can it be made to be "additive"?
  4. If the custom security policy replaces the default one, can we get the default policy so we can base our policy on it?
  5. I see in the docs this following:
    grant codeBase "file:${javacallout.dir}/-"  {
        permission java.security.AllPermission;
    }
    How can I determine the correct path for our java callout? Is this always the path?
  6. Does this path include all java-callouts on this hybrid setup?

For reference, I am attaching a stacktrace for the error we are seeing:

 

 

 

 

java.security.AccessControlException: access denied ("java.net.SocketPermission" "10.113.156.32:443" "connect,resolve") at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472) at java.base/java.security.AccessController.checkPermission(AccessController.java:897) at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322) at com.apigee.securitypolicy.InternalSecurityManager.checkPermission(InternalSecurityManager.java:65) at java.base/java.lang.SecurityManager.checkConnect(SecurityManager.java:824) at java.base/java.net.Socket.connect(Socket.java:604) at org.apache.http.conn.ssl.SSLConnectionSocketFactory.connectSocket(SSLConnectionSocketFactory.java:368) at org.apache.http.impl.conn.DefaultHttpClientConnectionOperator.connect(DefaultHttpClientConnectionOperator.java:142) at org.apache.http.impl.conn.PoolingHttpClientConnectionManager.connect(PoolingHttpClientConnectionManager.java:376) at org.apache.http.impl.execchain.MainClientExec.establishRoute(MainClientExec.java:393) at org.apache.http.impl.execchain.MainClientExec.execute(MainClientExec.java:236) at org.apache.http.impl.execchain.ProtocolExec.execute(ProtocolExec.java:186) at org.apache.http.impl.execchain.RetryExec.execute(RetryExec.java:89) at org.apache.http.impl.execchain.RedirectExec.execute(RedirectExec.java:110) at org.apache.http.impl.client.InternalHttpClient.doExecute(InternalHttpClient.java:185) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:83) at org.apache.http.impl.client.CloseableHttpClient.execute(CloseableHttpClient.java:108) at com.obfuscatedsec.DataSender.SendDataDebugMode(DataSender.java:110) at com.obfuscatedsec.ObfuscatedJavaCallout.handleResponse(ObfuscatedJavaCallout.java:251) at com.obfuscatedsec.ObfuscatedJavaCallout.execute(ObfuscatedJavaCallout.java:116) at com.apigee.steps.javacallout.JavaCalloutStepDefinition$ClassLoadWrappedExecution.execute(JavaCalloutStepDefinition.java:183) at com.apigee.steps.javacallout.JavaCalloutStepDefinition$SecurityWrappedExecution$1.run(JavaCalloutStepDefinition.java:282) at com.apigee.steps.javacallout.JavaCalloutStepDefinition$SecurityWrappedExecution$1.run(JavaCalloutStepDefinition.java:280) at java.base/java.security.AccessController.doPrivileged(Native Method) at com.apigee.steps.javacallout.JavaCalloutStepDefinition$SecurityWrappedExecution.execute(JavaCalloutStepDefinition.java:279) at com.apigee.steps.javacallout.JavaCalloutStepDefinition$CallOutWrapper.execute(JavaCalloutStepDefinition.java:114) at com.apigee.messaging.runtime.steps.StepExecution.execute(StepExecution.java:175) at com.apigee.flow.execution.AbstractAsyncExecutionStrategy$AsyncExecutionTask.call(AbstractAsyncExecutionStrategy.java:107) at com.apigee.flow.execution.AsyncExecutionStrategy.execute(AsyncExecutionStrategy.java:30) at com.apigee.flow.MessageFlowImpl.execute(MessageFlowImpl.java:593) at com.apigee.flow.MessageFlowImpl.resume(MessageFlowImpl.java:409) at com.apigee.flow.execution.ExecutionContextImpl.lambda$resume$0(ExecutionContextImpl.java:135) at com.apigee.threadpool.RunnableWrapperForMDCPreservation.run(RunnableWrapperForMDCPreservation.java:22) at com.apigee.threadpool.QueueMetricsAwareTask.run(QueueMetricsAwareTask.java:31) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:829)

 

 

 

 

Thanks!

0 3 304
3 REPLIES 3

Did you resolve this with Apigee support?

Apigee support confirmed that there is a bug.  We are waiting for the fix.

Has this been resolved? If not, can you share the bug/known-issue?