2 Securing Deployments
Microservices REST-based Service Interfaces are agnostic with regard to which underlying HTTP or HTTPS protocol is used. Their behavior is the same whether issued over a secure or an unsecure protocol.
Securing deployments involves enabling security through the security configuration when setting up a deployment for the first time using Oracle GoldenGate microservices. Administrators who are assigned the security role can change the details of the default MA security profile to control various aspects of secure operation. See How to Add Users 19c in Using the Oracle GoldenGate Microservices Architecture to know more about the security user role.
MA's default security configuration is ranked at a high-medium security level. By enabling security for an MA deployment, the default coordinated security profile from both inbound and outbound communications is enabled (excluding the client and server wallet location (WRL).
To secure a deployment, you can use your existing wallets and certificates, or create new ones. See Setting Up Secure and Non-Secure Deployments in Using the Oracle GoldenGate Microservices Architecture for more information.
- Creating a Self-Signed Root Certificate
In a secure mode, communication with Oracle GoldenGate MA including administrative calls and data transport is secured using TLS certificates, which you purchase or create your own for testing purposes. - Creating Server Certificates
- Creating a Distribution Server User Certificate
You have the option of using a client certificate or a username and password that is common to the Distribution Server deployment and the Receiver Server deployment. - Trusted Certificates
Thewsscommunication protocol is used in the Distribution Server for the Distribution Path to meet the needs of secure communication using TLS in Oracle GoldenGate Microservices Architecture.
Parent topic: Securing the Microservices Architecture
2.1 Creating a Self-Signed Root Certificate
In a secure mode, communication with Oracle GoldenGate MA including administrative calls and data transport is secured using TLS certificates, which you purchase or create your own for testing purposes.
In production environments, it is strongly recommended to use commercial
certificates. In test environments, you may create your own self signed certificates
using orapki or OpenSSL.
Each secure Oracle GoldenGate deployment requires two certificates: Server certificate for the Oracle GoldenGate services and a client certificate used by the distribution and/or receiver server to securely communicate with other remote deployments It is key that all certificates are signed by the same root certificate authority (rootCA). rootCA is the trustpoint. You use only one root certificate authority (rootCA) for all certificates across the deployment. For each server where Oracle GoldenGate is deployed, you have one specific Server Certificate.
You may apply your existing root certificate or use the orapki in the OGG_HOME/bin directory, see About the orapki Utility in the Oracle Database Security Guide.
Here's an example of how you can create a root certificate using orapki:
Parent topic: Securing Deployments
2.2 Creating Server Certificates
root_ca.
Parent topic: Securing Deployments
2.3 Creating a Distribution Server User Certificate
You have the option of using a client certificate or a username and password that is common to the Distribution Server deployment and the Receiver Server deployment.
orapki in the OGG_HOME/bin directory. For more
information about orapki, see About the orapki Utility in the Oracle Database Security Guide.
Parent topic: Securing Deployments
2.4 Trusted Certificates
The wss communication protocol is used in the Distribution
Server for the Distribution Path to meet the needs of secure communication using TLS
in Oracle GoldenGate Microservices Architecture.
There are two types of TLS connections and to use TLS, there are certain requirement for the certificate trust chain.
Distribution Server and Receiver Server
Both the Distribution Server and Receiver Server need certificates. The
Distribution Server uses the certificate in the client wallet
location under outbound section. The location of that wallet can be
found in the deploymentConfiguration.dat file under
deployment_home/etc/conf.
The certificates in both wallets need to be trusted by each other, so either both need to have commercial certificates issued by Classic architecture, or they have to trust each other for self-signed certificates.
-
Have both certificates signed by the same Root Certificate.
-
The other side’s certificate is added to the local wallet as trusted certificate
"distsrvr": {
"$schema": "ogg:service",
"config": {
"network": {
"serviceListeningPort": 9102
},
"authorizationDetails": {
"common": {
"allow": [
"Digest",
"x-Cert",
"Basic"
]
}
},
"authorizationEnabled": true,
"workerThreadCount": 24,
"legacyProtocolEnabled": true,
"taskManagerEnabled": true,
"security": false,
//The following is the outbound communication setup.
"securityDetails": {
"network": {
"outbound": {
"authMode": "client_server",
"crlEnabled": false,
"role": "client",
"wrl": "file:/u02/ogg/dpora12c/etc/ssl/740977c539e7",
"wrlPassword": ""
}In this example, the section that starts with securityDetails is for the outbound communication setup. The WRL values gives wallet location.
deploymentConfiguration.dat file, as shown
in the following
example.…
"recvsrvr" : {
"$schema" : "ogg:service",
"config" : {
"authorizationDetails" : {
"common" : {
"allow" : [ "Basic", "x-Cert" ]
}
},
"authorizationEnabled" : true,
"legacyProtocolEnabled" : true,
"network" : {
"serviceListeningPort" : 10083
},
"security" : true,
"securityDetails" : {
"network" : {
"common" : {
"authMode" : "clientOptional_server",
"blockSize" : 4096,
"cipherSuites" : [
"SSL_RSA_WITH_3DES_EDE_CBC_SHA",
"TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256",
"TLS_ECDHE_ECDSA_WITH_RC4_128_SHA",
"TLS_RSA_WITH_AES_256_GCM_SHA384"
],
"crlEnabled" : false,
"crlStore" : "file:",
"id" : "OracleSSL",
"protocolVersion" : "1_2_Or_1_1_Or_1_0_Or_3_0"
},
"inbound" : {
"role" : "server",
"wrl" : "file:/home/oracle/apps/OlnxSRCSSL/etc/ssl/OlnxSRC",
"wrlPassword" : ""
},
"outbound" : {
"role" : "client",
"wrl" : "file:/home/oracle/apps/OlnxSRCSSL/etc/ssl/oggdistclient",
"wrlPassword" : ""
}On the Distribution Server, if the hostname used in the Receiver Server’s
certificate can’t be routed correctly, /etc/hosts
file should be updated with the correct IP address for that host.
The Distribution Server will use this IP address to communicate with
the Receiver Server once it accepts the certificate from the
Receiver Server.
Using the Reverse Proxy (NGINX) with the Distribution Server and Receiver Server
You only need to add the Nginx certificate to the Distribution server’s client wallet as a trusted certificate. Usually the certificate used by Nginx is self-signed. If it is issued by Classic architecture, then there is no need to perform this step.
/etc/hosts file needs
to be updated to reflect the correct IP address for that host
name.The Distribution Server will use the host name in the
certificate to communicate to the target. If the NGINX certificate
doesn’t have a valid host name in it, but has a Subject Alternative
Name record, then the host name is the DNS name there. For
example:…X509v3 Subject Alternative Name:
DNS:localhost,
DNS:oggmp0802iad,
DNS:oggmp0802iad.sub06261535551.wernervcnab.oraclevcn.com,
DNS:127.0.0.1, IP Address:127.0.0.1…Parent topic: Securing Deployments