Learn how to secure your network for Oracle GoldenGate.
Topics:
Parent topic: Securing the Microservices Architecture
The MA configuration of the network connection takes the form of an array or network access control list (ACL).
Each ACL specification minimally consists of a permission statement indicating whether the APC specification allows or denies client connections from the specified address. ACL specifications are processed in order and terminate when the specified address is qualified. If the specified address does not qualify, processes continue with the next ACL specification. Once the address of the client requesting connection is qualified, the ACLs permissions dictate whether the connection is 'allowed' or 'denied'. If the no ACL specifications qualify address of the client requesting connection, a default resolution of 'allow is assumed and the client is allowed to connect. The ACL in the configuration take the following syntactic form:
ipACL := '[' aclSpec [, aclSpec] ']' aclSpec := "permission" : [ "deny" | "allow" ] [, "address": [ ipv4Address | ipv4MappedAddress | ipv6Address ] ] ipv4Address := '"' decimal '.' decimal '.' decimal '.' decimal '"' ipv4MappedAddress := '"' 'ff::' decimal '.' decimal '.' decimal '.' decimal '"' ipv6Address := '"' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal '"'
Inbound connection request are processed uniformly after they are received over a network interface. The network interface configuration dictates the form of addressing. For example, addresses appearing on an IPv6 interface appears as IPv6 addresses. If the IPv6 configuration specifies IPv4 mapping, then the IPv4 client's address is mapped into the IPv6 addressing space. An address appearing on an IPv4 interface appears as an unmapped IPv4 address. Since the ACL qualification focuses on qualifying addresses and all adapters within the host environment have unique addresses, no additional interface information is required.
For hosts that support hot-fail over network interfaces, the fail-over and reassignment of network IP address to adapter MAC addresses is transparent to the application.
Example 2-1 Examples
Deny client connections originating from 192.0.2.254.
"ipACL" : [ { "permission" : "deny", "address" : "192.0.2.254" } ]
Explicitly allow all client connections. The first ACP by default qualifies all addresses. The second ACL is never processed.
"ipACL" : [ { "permission" : "allow" },
{ "permission" : "deny", "address" : "192.0.2.254" } ]
Allow client connections originating from 127.0.0.1, but deny connection originating from 192.0.2.254 appearing on an interface configured for IPv6 addressing.
"ipACL" : [ { "permission" : "allow", "address" : "127.0.0.1" },
{ "permission" : "deny", "address" : "ff::192.0.2.254" } ]
Allow client connections originating from and IPv6 loopback address (127.0.0.1 represented as ::1 in IPV6 addressing), allow client connections originating from the unmapped IPv4 address 192.0.2.253, allow client connections originating from IPv6 address 2001:db8:85a3:0:0:8a2e:370:7334 and deny client connections originating from mapped IPv4 address ff::192.0.2.254.
"ipACL" : [ { "permission" : "allow", "address" : "::1" },
{ "permission" : "allow", "address" : "192.0.2.254" },
{ "permission" : "allow", "address" : "2001:db8:85a3:0:0:8a2e:370:7334" },
{ "permission" : "deny", "address" : "ff::192.0.2.254" } ]
Parent topic: Network
Learn about how to specify your network connection configuration.
An adapter class is used to encapsulate the logic and implementation of acquiring network listening address configuration and establishing listening port based on the network configuration. The actual network connection information is captured in Network Connection Specification of the Software Communications Architecture (SCA). In the description of the ScaNetworkSpec class, instances of the ScsNetworkSpec represent the network configuration information acquired from the ScaSharedContext. The ScaNetworkSpec handles the discrete network specification. However, a complete SCA network specification takes any of three forms and can define more than one network configuration. Multiple networks is when more than one network interface is configured in an environment where the host be multi-homed, For example, handling connections requests on different addresses through different network interface adapters.
The NetworkConnectionSpecs themselves are members of an array associated with the serviceListeningPort configuration element. For example, using the serviceListeningPort configuration entry, an SCA network specification may take any of the following syntactic forms:
1. portValue | portValueString 2. networkSpec 3. '[' networkSpec [, networkSpec ...] ']'
You can use the following syntax in your network specification:
portValue := [1234567890]+ portValueString := '"' portValue '"' networkSpec := '{' portSpec [, ipaddressSpec | nameSpec] [, interfaceSpec] [, networkOptionSpec] '}' portSpec := "port" : portValue | portValueString ipaddressSpec := "address" : ipv4Address | ipv6Address | "ANY" nameSpec := '"' :alphanum: '"' interfaceSpec := "interface" : '"' :alphanum: '"' networkOptionSpec := "options" : IPV4_ONLY | IPV6_ONLY
Regardless of the form your specification takes, the internal representation is normalize into the 3rd form:
1. portValue | portValueString == networkSpec 2. portValue == '{' "port" : portValue '}' 3. portValueString == '[' '{' "port" : portValueString '}' ']'
The first form retains compatibility with existing network port specifications where only the portValue or portValueString is provided.
The second form assigns the networkSpec as a single value. This form still only defines a single network specification and allows greater control and flexibility in identifying network values and options.
The third form defines an array of networkSpec instances. It allows you to specify different network configurations based upon either address or network interface.
Example 2-2 Example
With the following simplified host network interface configuration:
$/sbin/ip addr show lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:16:3e:52:6e:27 brd ff:ff:ff:ff:ff:ff inet 192.0.2.39/21 brd 10.240.111.255 scope global eth0 inet6 2001:db8:85a3:0:0:8a2e:370:6666 brd ff02::1 scope link eth0 eth1: BROADCAST,MULTICAST mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:16:3e:1f:99:bc brd ff:ff:ff:ff:ff:ff inet 192.0.2.98/21 brd 10.100.99.98 scope link eth1 inet6 2001:db8:85a3:0:0:8a2e:370:7334 brd ff02::1 scope link eth1
The following specification is derived:
1. "serviceListeningPort: "9000"
2. "serviceListeningPort: 9000
3. "serviceListeningPort: { "port" : 9000 }
4. "serviceListeningPort: { "port" : "9000" }
5. "serviceListeningPort: { "port" : "9000", "address" : "192.0.2.254" }
6. "serviceListeningPort: { "port" : "9000", "name" : "server1" }
7. "serviceListeningPort: { "port" : "9000", "interface" : "eth1" }
8. "serviceListeningPort: [
{ "port" : "9000", "interface" : "lo" }
{ "port" : "9000", "address" : "192.0.2.39", "option" : "IPV4_ONLY" }
{ "port" : "9000", "interface" : "eth1", "option" : "IPV6_ONLY" }
These forms are describes as:
Listens on port 9000 on all ANY address over ALL interfaces.
Listens on port 9000 on address 192.0.2.254 only.
Listens on port 9000 on the address associates with server1.
Listens on port 9000 on the address associates with interface eth1 and accepts IPV4 address connections using the mapped IPV4.
Listens on port 9000 on the address associates with interface lo, on port 9000 address 192.0.2.39 accepting only IPV4 addresses, and on port 9000 with addresses associated with interface eth1 accepting onlyIPV6 addresses.
Most of the logic encapsulated within this class handles selecting network interface adapter based on the network interface adapter’s identifying name or the address. The interface can be searched for based on the requested address.
Specifying multiple adapters means that each ScaNetworkSpec resolves to only a subset of adapters. Precedence processing allows the specification of ANY address and ALL interfaces for the last ScaNetworkSpec as a pool specification when the platform networking interfaces support mapping sub-set interface matches
Parent topic: Network
Learn how to configure your proxy servers.
Proxy configuration mediates access with different MA servers within a network for a deployment.
MA requires you to exhibit proper and compliant behavior in a network environment where one or more proxy servers may mediate access to MA servers.
Configuration
The initial configuration is simply declaring whether proxy detection should be enabled or disabled. Typically, it is enabled by default though you can disable it in /config/network/proxyDetails. The enable clause is similar to:
{
"network" : {
"proxyEnabled": true,
"proxyDetails": {
"proxyACLEnabled": true,
"proxyACL": [
{ "permission": "deny", "address": "192.0.2.254" },
{ "permission": "allow", "address": "192.0.2.254", "trusted": false },
{ "permission": "allow", "address": "ANY", "trusted": true }
],
"urlMappingEnabled": true,
"urlMapping": [
]
}
}
}
Proxy ACL Specifications
The configuration of Proxy ACL specifications is similar to Network IP ACL specifications. The differences are that each entry defines the access control for a proxy server in your environment and includes a trust designator. Each ACL specification minimally consists of a permission statement indicating whether the ACL specification allows or denies client connections proxied through the proxy server's specified address. ACL specifications are processed in order and terminate when the specified address is qualified. If the specified address does not qualify, processes continue with the next ACL specification. Once the address of the client requesting connection is qualified, the ACLs permissions dictate whether the connection is allowed or denied. If the no ACL specifications qualify address of the client requesting connection, a default resolution of allow is used and the client is allowed to connect. The ACL in the configuration may take the following form:
ipACL := '[' aclSpec> [, aclSpec] ']' aclSpec := "permission" : [ "deny" | "allow" ] [, "address": [ ipv4Address | ipv4MappedAddress | ipv6Address ] ] ipv4Address := '"' decimal '.' decimal '.' decimal '.' decimal '"' ipv4MappedAddress := '"' 'ff::' decimal '.' decimal '.' decimal '.' decimal '"' ipv6Address := '"' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal ':' hexadecimal '"'
Example 2-3 Proxy Examples
Deny client connections originating from 192.0.2.254.
"ipACL" : [ { "permission" : "deny", "address" : "192.0.2.254" } ]
Explicitly allow all client connections. The first ACP by default qualifies all addresses. The second ACL is never processed.
"ipACL" : [ { "permission" : "allow" },
{ "permission" : "deny", "address" : "192.0.2.254" } ]
Allow client connections originating from 127.0.0.1, but deny connection originating from 192.0.2.254 appearing on an interface configured for IPv6 addressing.
"ipACL" : [ { "permission" : "allow", "address" : "127.0.0.1" },
{ "permission" : "deny", "address" : "ff::192.0.2.254" } ]
Allow client connections originating from and IPv6 loopback address (127.0.0.1 represented as ::1 in IPV6 addressing), allow client connections originating from the unmapped IPv4 address 192.0.2.253, allow client connections originating from IPv6 address 2001:db8:85a3:0:0:8a2e:370:7334 and deny client connections originating from mapped IPv4 address ff::192.0.2.254.
"ipACL" : [ { "permission" : "allow", "address" : "::1" },
{ "permission" : "allow", "address" : "192.0.2.254" },
{ "permission" : "allow", "address" : "2001:db8:85a3:0:0:8a2e:370:7334" },
{ "permission" : "deny", "address" : "ff::192.0.2.254" } ]
Parent topic: Network
Learn how to configure your reverse proxy servers.
Reverse Proxy allows a single point of contact for various microservices associated with an Oracle GoldenGate MA deployment.
You can configure a proxy server depending on your environment setup and network requirements. Reverse proxy is optional, however, it is recommended to ensure easy access to microservices and provide enhanced security.
Reverse Proxy Support
Oracle GoldenGateMA can be configured to use a reverse proxy. Oracle GoldenGate MA includes an application called ReverseProxySettings that generates configuration file for a reverse proxy server. For example, the Administration Server is available on https://goldengate.example.com:9001 and the Distribution Server is on https://goldengate.example.com:9002. With reverse proxy, all the microservices can be accessed from a single address, for example, https://goldengate.example.com.
ReverseProxySettings application has two additional parameters in Oracle GoldenGateversion 12.3.0.1 or later:
-P: Password for a Service Manager account.
-u: Name of the Service Manager account to use.
These values are used when connecting to the Service Manager and are required when authentication is enabled.
Prerequisites
If you need to use a reverse proxy service with MA, use Nginx. Its a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server.Oracle GoldenGate MA is shipped with a utility to configure Nginx reverse proxy.
Install Nginx: For Oracle Linux, the command to install Nginx is:
yum —y install nginx
For more information about installing Nginx, see Installing Nginx Reverse Proxy
Check the JRE version to be JRE 8.
Install Oracle GoldenGate MA.
Create one or more active MA deployments.
Configuring Nginx-based Reverse Proxy Example
An Oracle GoldenGate MA installation includes the ReverseProxySettings application in the $OGG_HOME/lib/utl/reverseproxy/directory. You can see the list of options available with the application, using the –help command.
$OGG_HOME/lib/utl/reverseproxy/ReverseProxySettings --help
Usage: proxysettings [options] service-manager-url
Options:
-o, --output Output file name (default is ogg.conf)
-l, --log Log file name (default is no logging)
-t, --type Proxy server type (default is nginx)
-s, --no-ssl Configure without SSL
-h, --host Virtual host name for reverse proxy
-p, --port Reverse proxy port number (defaults to 80 or 443)
-?, --help Display usage information
-v, --version Display version
Follow these steps to configure a reverse proxy:
To create the settings file for Nginx:
$OGG_HOME/lib/utl/reverseproxy/ReverseProxySettings -u admin id -P admin password -o ogg.conf http://localhost:9100
sudo mv ogg.conf /etc/nginx/conf.d/
Create your self-signed certificate for Nginx, using the following command:
sudo sh /etc/ssl/certs/make-dummy-cert /etc/nginx/ogg.pem
Test the new Nginx configuration using the following command:
sudo nginx -t nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful
As root, reload Nginx and the new configuration:
sudo nginx -s reload
Use Curl to verify that reverse proxy is working:
curl -sv http://localhost/services/v2
{"$schema":"api:version","catalog":{"links":[
{"href":"http://localhost/service s/v2/metadata-catalog","rel":"canonical"}]},"isLatest":true,"lifecycle":"active","links":[
{"href":"http://localhost/services/v2","mediaType":"application/js on","rel":"canonical"},
{"href":"http://localhost/services/v2","mediaType":"app lication/json","rel":"self"}],"version":"v2"}
Note:
If the deployments associated with the target Service Manager change, the Nginx configuration file must be re-generated and reloaded.Parent topic: Network