IBM Data and AI Ideas Portal for Customers

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Post your ideas

Post ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,

  1. Post an idea

  2. Upvote ideas that matter most to you

  3. Get feedback from the IBM team to refine your idea

Help IBM prioritize your ideas and requests

The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The product management team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.

Receive notification on the decision

Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas which cannot be implemented in a reasonable time.

Additional Information

To view our roadmaps:

Reminder: This is not the place to submit defects or support needs, please use normal support channel for these cases

IBM Employees:

The correct URL for entering your ideas is:

Status Not under consideration
Created by Guest
Created on Mar 6, 2018

Data Catalog dynamic IP address frustrates IP address security filters in remote clouds and on-premise systems.

I'm testing the Data Catalog's ability to access a remote(to IBM's cloud) relational database.  I provisioned a NoSQL database using AWS RDS service.  I wanted to set the AWS security group to only permit access from the IP address used by the Data Catalog.  I used AWS logging to determine the IP address used by Data Catalog and set the security group to permit access from that IP.  Data Catalog was able to access the MySQL database and access the data.  However, the next day it stopped working.  Reviewing the access logs on AWS showed the IP address used by the Data Catalog had changed.  I tried this several different times and at some point the IP address of the Data Catalog would change (the "From" address as seen by the AWS security group.) The class-A subnet also changed making it impossible to create a generic IBM cloud filter.  I realize IP addresses are a bad approach but, unfortunately, are in use as security filters by clouds and on-premise systems. 

Is there any way to specify a public IP address for the Data Catalog to use that doesn't change?   

I don't know if the observed behavior is coming from Data Catalog or the networking layer of Bluemix and/or Softlayer. 

My next step is to try setting up a Security Gateway between Bluemix and AWS with the idea I can get the Data Catalog to use the Security Gateway to tunnel over to a virtual lan segment at AWS where the database resides. 


Thank you

  • Guest
    Dec 14, 2018

    Work with Domenico Conia ... essentially each IBM data center has an IP range for outgoing connections.  We need to get that documented.

    Hi David,
    I did a good discussion and also some of these info was present in the deck
    you saw 30min ago in the "Public Isolation" Webinar.

    I don't have time today to prepare a good simple diagram
    but here the answer to your question.

    Short answer:  YES , as I said you before the traffic coming from a customer account is in the 90% of the cases simple to "white-list".

    A- Customer account managed by IBM:
        Secure Perimeter can be Vyatta 5600 or Fortigate FW

    B- Customer account managed by the customer
        Secure perimeter can be  Vyatta 5600 or Fortigate FW
        or any "customized" secure solution they want to put.
    The main architecture is not changing, with Scenario B the customer is responsible to manage the security

    There are 2 Scenarios available today :

    1-Vyatta Based Perimeter     ==> Source NAT is always configured on the Vyatts by BMX network engineer
                                                      so all the out-coming traffic to internet has 1 or  a few specific public IPs as source
                                                      (configured on the Vyatta or equivalent firewall)
                                                      CF Accounts

    2- Armada Based Perimeter  ==> Source NAT is still configured but on IP Tables
                                                      Project name: "BedRock" 
                                                     Fred Tucci is the lead architect for this project.
                                                     They use Front End Armada nodes as "secure perimeter" with IP Tables on board
                                                     Application runs on Back End Armada Nodes.
                                                     Armada Accounts

    Both scenario (Vyatta-Vyatta less) MUST be monitor to avoid the risk of
    missing-wrong firewall rules.
    IPTables (scenario 2) can be a mess with a lot of Fred is probably using automation
    to deploy and monitor the IP Tables. IF one rule is wrong (e,g, they forgot any any any allowed)
    an alarm is notified.

    On Scenario 1-Vyatta- this is alsways included in the BMX security architecture (vyatta fw rules are monitored).

    FUTURE Scenario:                         
    3- Another scenario (not possible today, could be in a few months hopefully) is BYOP
        With BYOP the customer could assign speficic addresses as Source or his environment

    Kind regards
    Domenico Conia
    IBM Italia S.p.A.                              Mobile: +39 3357446011
    IBM Watson Data Platform             Infrastructure team
    Certified Expert IT Architect Cloud & Security

    IBM Italia S.p.A. Sede Legale: Circonvallazione Idroscalo - 20090 Segrate (MI) Cap. Soc. euro 347.256.998,80 C. F. e Reg. Imprese MI 01442240030 - Partita IVA 10914660153 Societa' con unico azionista Societa' soggetta all'attivita' di direzione e coordinamento di International Business Machines Corporation (Salvo che sia diversamente indicato sopra / Unless stated otherwise above)