Oracle recommends not exposing any administrative, RMI, or T3 channels outside the Kubernetes cluster unless absolutely necessary.
If exposing an administrative, RMI, EJB, JMS, or T3 capable
channel using a load balancer,
NodePorts, or similar,
then limit access by using a custom
dedicated WebLogic Server port that you have configured
with the T3 or administration protocol (a network access point)
instead of relaying the traffic to a default port,
leverage two-way SSL, use controls like security lists,
and/or set up a Bastion to provide access. A custom channel
is preferred over a default channel because a default port supports
When accessing T3 or RMI based channels for administrative purposes,
such as running WLST, the preferred approach is to
kubectl exec into
the Kubernetes Pod and then run
wlst.sh, or set up Bastion access and then run
java weblogic.WLST or
from the Bastion host to connect to the Kubernetes cluster
(some cloud environments use the term Jump Host or Jump Server instead of Bastion).
Also, if you need to use cross-domain T3 access between clouds, data centers, and such, consider a private VPN.
When providing remote access to HTTP using a load balancer,
NodePorts, or similar,
Oracle recommends relaying the traffic to a dedicated
WebLogic Server port that you have configured
using a custom HTTP channel (network access point)
instead of relaying the traffic to a default port.
This helps ensure that external
traffic is limited to the HTTP protocol. A custom HTTP channel
is preferred over a default port because a default port supports
Do not enable tunneling on an HTTP channel that is exposed for remote access unless you specifically intend to allow it to handle T3 traffic (tunneling allows T3 to tunnel through the channel using HTTP) and you perform the additional steps that may be necessary to further secure access, as described in WebLogic T3 and administrative channels.
NodePorts are good for use in demos and getting-started guides,
they are typically not suited for production systems for multiple reasons, including:
NodePort may implicitly expose a port to the public Internet.
NodePorts because their Kubernetes clusters run on a private network that cannot be reached by external clients.
Set up administration ports: Configure an administration port on WebLogic, or an administrative channel, to prevent all other channels from accepting administration-privileged traffic (this includes preventing administration-privileged traffic from a WebLogic console over HTTP).
Be aware of anonymous defaults: If an externally available port supports a protocol suitable for WebLogic JNDI, EJB/RMI, or JMS clients, then note that by default:
Configure SSL: You can configure two-way SSL to help prevent external access by unwanted applications (often SSL is setup between the caller and the load balancer, and plain-text traffic flows internally from the load balancer to WebLogic).