Tuesday, April 27, 2021

Use separate cer for separate domain with nginx ingress in kubernetes

 We have nginx  ingress to control https service and forward to backend in kubernetes. We want some thing like domain abc.com should use "abc.com" 's certificate  and  domain xyz.com should use "xyz.com" 's certificate.

Step 1: Create TLS Secrets

Anytime we reference a TLS secret, we mean a PEM-encoded X.509, RSA (2048) secret.

You can generate a self-signed certificate and private key with:

$ openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout abc.key -out abc.cer -subj "/CN=abc.com/O=abc.com"

Then create the secret in the cluster via:

$kubectl create secret tls abc --key abc.key --cert abc.cer

The resulting secret will be of type kubernetes.io/tls.

We add same tls for xyz.com domain.

Step 2: Add ingress resource 

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    # Enable client certificate authentication
    nginx.ingress.kubernetes.io/auth-tls-verify-client: "on"
    # Create the secret containing the trusted ca certificates
    nginx.ingress.kubernetes.io/auth-tls-secret: "default/ca-secret"
    # Specify the verification depth in the client certificates chain
    nginx.ingress.kubernetes.io/auth-tls-verify-depth: "1"
    # Specify an error page to be redirected to verification errors
    nginx.ingress.kubernetes.io/auth-tls-error-page: "http://www.mysite.com/error-cert.html"
    # Specify if certificates are passed to upstream server
    nginx.ingress.kubernetes.io/auth-tls-pass-certificate-to-upstream: "true"
  name: nginx-test
  namespace: default
spec:
  rules:
  - host: abc.com
    http:
      paths:
      - backend:
          serviceName: http-svc
          servicePort: 80
        path: /
  tls:
  - hosts:
    - abc.com
    secretName: abc

Ref: https://kubernetes.github.io/ingress-nginx/examples/auth/client-certs/

Add the DNS entry to DNSCore in kubernetes

 Edit configmap with name coredns in namespace 

kubectl edit cm coredns   -n kube-system

apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
log
health
rewrite name foo.example.com foo.default.svc.cluster.local
kubernetes cluster.local 10.0.0.0/24
file /etc/coredns/cluster.db cluster.local
proxy . /etc/resolv.conf
cache 30
}
cluster.db: |

cluster.local.               IN      SOA     ns.dns.cluster.local. hostmaster.cluster.local. 2015082541 7200 3600 1209600 3600

something.cluster.local.     IN      A       10.0.0.1

otherthing.cluster.local.    IN      CNAME   google.com.

Add the highlight  content above( The example.db is included dns entries the you want to add).

and we also need to edit the volumes section of the Pod template spec(DNSCore deployment):
      volumes:

and we also need to edit the volumes section of the Pod template spec:

volumes:
- name: config-volume
configMap:
name: coredns
items:
- key: Corefile
path: Corefile
- key: cluster.db
path: 
cluster.db

Ref: https://coredns.io/2017/06/08/how-queries-are-processed-in-coredns/

Friday, April 23, 2021

Use Multicast to keep the request body

 In the Redhat Fuse, when we route to the target system( like API, Database) the body will be overwrite with the response for  target system. In case we want access the data from the request, we should use  Multicast.



With the route above, The request will duplicate  to 2 route ( _route2 and _route3 ) and merge  the response of those route to  it body ( it 's array of  responses ). So, because the _route2 just  echo the message then we can access the  origin request.
And we can access the merge  of those response like access the array
 



Control plane node isolation

 By default, your cluster will not schedule Pods on the control-plane node for security reasons. If you want to be able to schedule Pods on the control-plane node, for example for a single-machine Kubernetes cluster for development, run:

kubectl taint nodes --all node-role.kubernetes.io/master-

With output looking something like:

node "test-01" untainted
taint "node-role.kubernetes.io/master:" not found
taint "node-role.kubernetes.io/master:" not found

This will remove the node-role.kubernetes.io/master taint from any nodes that have it, including the control-plane node, meaning that the scheduler will then be able to schedule Pods everywhere

Ref: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/

Configuring WSO2 API Manager 3.x with Tibco EMS (JMS)

  1. Open the deployment.toml file present at on repository/component/conf directory and add the following JMSSender configurations.

    If you use 127.0.0.1 host for the Tibco server, the APIM server should need to start at the same host.

    [[transport.jms.sender]]

    name = “QueueConnectionFactoryAPIM”

    parameter.initial_naming_factory =

    "com.tibco.tibjms.naming.TibjmsInitialContextFactory"

    parameter.provider_url = "tcp://127.0.0.1:7222"

    parameter.connection_factory_name = "QueueConnectionFactoryAPIM"

    parameter.connection_factory_type = "queue"

    parameter.jms_spec_version = "1.0.2b"

    parameter.username = "admin"

    parameter.password = ""

    parameter.destination_type = "queue"

    parameter.default_reply_destination = "queue"

     

  2. Placed the following jars (jms lib for Tibco ) on <APIM_HOME>/repository/components/extensions directory of the APIM server ( jms-2.0.jar, tibjms.jar, tibjmsadmin.jar, tibjmsapps.jar,tibrvjms.jar)
  3. Start the server

    Once you open the axis2.xml file residing on <APIM_HOME>/repository/components/conf/axis2/ directory; you can see the following JMSSende configurations.

    <transportSender class=”org.apache.axis2.transport.jms.JMSSender” name=”jms”>

    <parameter locked=”false” name=”QueueConnectionFactoryAPIM”>

    <parameter locked=”false” name=”java.naming.factory.initial”>com.tibco.tibjms.naming.TibjmsInitialContextFactory</parameter>

    <parameter locked=”false”

    name=”java.naming.provider.url”>tcp://127.0.0.1:7222</parameter>

    <parameter locked=”false”

    name=”transport.jms.UserName”>admin</parameter>

    <parameter locked=”false” name=”transport.jms.Password”></parameter>

    <parameter locked=”false”

    name=”transport.jms.ConnectionFactoryJNDIName”>QueueConnectionFactoryAPIM</parameter>

    <parameter locked=”false”

    name=”transport.jms.ConnectionFactoryType”>queue</parameter>

    <parameter locked=”false”

    name=”transport.jms.DefaultReplyDestinationType”>queue</parameter>

    <parameter locked=”false”

    name=”transport.jms.JMSSpecVersion”>1.0.2b</parameter>

    <parameter name=”transport.jms.MaxJMSConnections”>5</parameter>

    </parameter>

    </transportSender>


  4. Create an API with the following endpoint (add the wild card resource path to a POST resource)

    For dual-channel temporary queue scenario, the endpoint would be like,

    jms:/Request?transport.jms.ConnectionFactory=QueueConnectionFactoryAPIM&amp;transport.jms.ContentTypeProperty=Content_Type&amp;transport.jms.DestinationType=queue&amp;transport.jms.Destination=Req

    For the dual-channel scenario with the predefined queues as request and response, the endpoint would be like,

    jms:/Request?transport.jms.ConnectionFactory=QueueConnectionFactoryAPIM&amp;transport.jms.ContentTypeProperty=Content_Type&amp;transport.jms.DestinationType=queue&amp;transport.jms.Destination=Request&amp;transport.jms.ReplyDestination=Response

  5. Publish the API.
Ref: 
https://medium.com/@hiranyakavi/configure-tibco-ems-jms-transport-scenario-with-wso2-api-manager-3-x-d4c5e0cb774b

Note:

Add The reponse mediator to  fix null pointer exception with following content:

<sequence xmlns="http://ws.apache.org/ns/synapse" name="addToResponse"> 
   <property name="HTTP_SC" value="200" scope="axis2" />
</sequence>

Thursday, December 24, 2020

OHS the plug-ins do not fail over

 

CAUSE

The multiple invocations had nothing to do with OSB, rather with the configuration of the plugin for the Apache load balancer. This is expected behavior for the default 11g configuration in certain situations. The issue is due to the use of the plugin configuration parameter "Idempotent".

When "Idempotent" is turned on, the plugin will attempt to resend the HTTP request after it has timed out (configured in the "WLIOTimeoutSecs" parameter in plugin).

http://download.oracle.com/docs/cd/E13222_01/wls/docs100/plugins/plugin_params.html

 

Unsolicited multiple invocations like this have been reported in other products using the same load balancer configuration.

SOLUTION

 

  1. Turn OFF Idempotent in the web server plugin configuration.
    http://download.oracle.com/docs/cd/E13222_01/wls/docs100/plugins/plugin_params.html
    If "Idempotent" is set to “OFF” the plugin will not fail over.
  2. If not explicitly set, WLIOTimeoutSecs defaults to 300 seconds (5 minutes).
    You can add a line in the file httpd.conf ($ORACLE_INSTANCE/config/OHS/ohsx) in order to set this parameter WLIOTimeoutSecs

Wednesday, December 23, 2020

OHS Terminating SSL Requests

 

Terminating SSL Requests

The following sections describe how to terminate requests using SSL before or within Oracle HTTP Server, where the mod_wl_ohs module forwards requests to WebLogic Server. Whether you terminate SSL before the request reaches Oracle HTTP Server or when the request is in the server, depends on your topology. A common reason to terminate SSL is for performance considerations when an internal network is otherwise protected with no risk of a third-party intercepting data within the communication. Another reason is when WebLogic Server is not configured to accept HTTPS requests.

This section includes the following topics:

About Terminating SSL at the Load Balancer

If you are using another device such as a load balancer or a reverse proxy which terminates requests using SSL before reaching Oracle HTTP Server, then you must configure the server to treat the requests as if they were received through HTTPS. The server must also be configured to send HTTPS responses back to the client.

Figure 9-1 illustrates an example where the request transmitted from the browser through HTTPS to WebLogic Server. The load balancer terminates SSL and transmits the request as HTTP. Oracle HTTP Server must be configured to treat the request as if it was received through HTTPS.

Figure 9-1 Terminating SSL Before Oracle HTTP Server

Description of Figure 9-1 follows
Description of "Figure 9-1 Terminating SSL Before Oracle HTTP Server"
Terminating SSL at the Load Balancer

To instruct the Oracle HTTP Server to treat requests as if they were received through HTTPS, configure the httpd.conf file with the SimulateHttps directive in the mod_certheaders module.

For more information on mod_certheaders module, see mod_certheaders Module—Enables Reverse Proxies.

Note:

This procedure is not necessary if SSL is configured on Oracle HTTP Server (that is, if you are directly accessing Oracle HTTP Server using HTTPS).

  1. Configure the httpd.conf configuration file with the external name of the server and its port number, for example:
    ServerName <www.company.com:port>
    
  2. Configure the httpd.conf configuration file to load the mod_certheaders module, for example:
    • On UNIX:

      LoadModule certheaders_module libexec/mod_certheaders.so
      
    • On Windows:

      LoadModule certheaders_module modules/ApacheModuleCertHeaders.dll
      AddModule mod_certheaders.c
      

      Note:

      Oracle recommends that the AddModule line should be included with other AddModule directives.

  3. Configure the SimulateHttps directive at the bottom of the httpd.conf file to send HTTPS responses back to the client, for example:
    # For use with other load balancers and front-end devices:
    SimulateHttps On
    
  4. Restart Oracle HTTP Server and test access to the server. Especially, test whether you can access static pages such as https://host:port/index.html

    Test your configuration as a basic setup. If you are having issues, then you should troubleshoot from here to avoid overlapping with other potential issues, such as with virtual hosting.

  5. Ideally, you may want to configure a VirtualHost in the httpd.conf file to handle all HTTPS requests. This separates the HTTPS requests from the HTTP requests as a more scalable approach. This may be more desirable in a multi-purpose site or if a load balancer or other device is in front of Oracle HTTP Server which is also handling both HTTP and HTTPS requests.

    The following sample instructions load the mod_certheaders module, then creates a virtual host to handle only HTTPS requests.

    # Load correct module here or where other LoadModule lines exist:
    LoadModule certheaders_module libexec/mod_certheaders.so
    # This only handles https requests:
       <VirtualHost <name>:<port>
           # Use name and port used in url:
           ServerName <www.company.com:port>
           SimulateHttps On
           # The rest of your desired configuration for this VirtualHost goes here
       </VirtualHost>
    
  6. Restart Oracle HTTP Server and test access to the server, First test a static page such as https://host:port/index.html and then your test your application.

About Terminating SSL at Oracle HTTP Server

If SSL is configured in Oracle HTTP Server but not on Oracle WebLogic Server, then you can terminate SSL for requests sent by Oracle HTTP Server.

The following figures illustrate request flows, showing where HTTPS stops. In Figure 9-2, an HTTPS request is sent from the browser. The load balancer transmits the HTTPS request to Oracle HTTP Server. SSL is terminated in Oracle HTTP Server and the HTTP request is sent to WebLogic Server.

Figure 9-2 Terminating SSL at Oracle HTTP Server—With Load Balancer

Description of Figure 9-2 follows
Description of "Figure 9-2 Terminating SSL at Oracle HTTP Server—With Load Balancer"

In Figure 9-3 there is no load balancer and the HTTPS request is sent directly to Oracle HTTP Server. Again, SSL is terminated in Oracle HTTP Server and the HTTP request is sent to WebLogic Server.

Figure 9-3 Terminating SSL at Oracle HTTP Server—Without Load Balancer

Description of Figure 9-3 follows
Description of "Figure 9-3 Terminating SSL at Oracle HTTP Server—Without Load Balancer"
Terminating SSL at Oracle HTTP Server

To instruct the Oracle HTTP Server to treat requests as if they were received through HTTPS, configure the WLSProxySSL directive in the mod_wl_ohs.conf file and ensure that the SecureProxy directive is not configured.

  1. Configure the mod_wl_ohs.conf file to add the WLSProxySSL directive for the location of your non-SSL configured managed servers.
    For example:
    WLProxySSL ON
    
  2. If using a load balancer or other device in front of Oracle HTTP Server (which is also using SSL), you might need to configure the WLProxySSLPassThrough directive instead, depending on if it already sets WL-Proxy-SSL.
    For example:
    WLProxySSLPassThrough ON
    

    For more information, see your load balancer documentation. For more information on WLProxySSLPassThrough, see Parameters for Oracle WebLogic Server Proxy Plug-Ins in Using Oracle WebLogic Server Proxy Plug-Ins.

  3. Ensure that the SecureProxy directive is not configured, as it will interfere with the intended communication between the components.
    This directive is to be used only when SSL is used throughout. The SecureProxy directive is commented out in the following example:
    # To configure SSL throughout (all the way to WLS):
    # SecureProxy ON
    # WLSSLWallet  "<Path to Wallet>" 
    
  4. Enable the WebLogic Plug-In flag for your managed servers or cluster.
    By default, this option is not enabled. Complete the following steps to enable the WebLogic Plug-In flag:
    1. Log in to the Oracle WebLogic Server Administration Console.
    2. In the Domain Structure pane, expand the Environment node.
    3. Click on Clusters.
    4. Select the cluster to which you want to proxy requests from Oracle HTTP Server.
      The Configuration: General tab appears.
    5. Scroll down to the Advanced section, expand it.
    6. Click Lock and Edit.
    7. Set the WebLogic Plug-In Enabled to yes.
    8. Click Save and Activate the Changes.
    9. Restart the servers for the changes to be effective.
  5. Restart Oracle HTTP Server and test access to a Java application.
    For example: https://host:port/path/application_name.

Install and use xorg-server on macOS via Homebrew

  The instructions to install and use xorg-server on macOS via Homebrew: Install Homebrew (if you haven't already): /bin/bash -c ...