In our case, we want to forge a secure connection between our virtual machine and the GridDB Cloud instance. With this in place, we can connect to GridDB Cloud via a normal java\/python source code and use it outside of the context of the Web API.<\/p>\n
How to Set Up a Virtual Network Peering Connection<\/h3>\n
Before you start on the GridDB Cloud side, you will first need to create some resources on the Microsoft Azure side. On Azure, create a Virtual Network<\/a> (VNet).<\/p>\n You will also need to eventually set up a virtual machine that is on the same virtual network that you just created (which will be the one you link with GridDB Cloud below). With these two resources created, let’s move on to the GridDB Cloud side.<\/p>\n For this part of the process, you can read step-by-step instructions here in the official docs: https:\/\/www.toshiba-sol.co.jp\/pro\/griddbcloud\/docs-en\/v3_1\/cloud_quickstart_guide_html\/GridDB_Cloud_QuickStartGuide.html#connection-settings-for-vnet<\/a>.<\/p>\n From the network tab, click ‘Create peering connection’ and you’ll see something like this pop up.<\/p>\n Here’s a summary of the steps needed to forge the vnet peering connection:<\/p>\n All of these steps are also plainly laid out in the GridDB Cloud UI — it should be a fairly simple process through and through.<\/p>\n Once your connection is forged, you should be able to connect to the GridDB Cloud instance using the notification provider address provided in your GridDB Cloud UI Dashboard.<\/p>\n If you want to do a very quick check before trying to run sample code, you can download the json file and use a third-party network tool like If a connection is made, everything is working properly.<\/p>\n And now you can run the sample code included in this repo. There is Java code for both NoSQL and SQL interfaces as well as Python code. To run the java code, you need to install java and maven. The sample code will create tables and read those tables, but also expects for you to ingest a To ingest the dataset, first navigate to the Here is the line of code that will transform the ts col into something the GridDB Web API likes.<\/p>\n You can make out from the format that it needs it to be like this: Next, you must create the container within your GridDB Cloud. For this part, you can use the GridDB Cloud CLI tool<\/a> or simply use the GridDB Cloud UI. The schema we want to ingest is found within the To create the table with the tool, simply run: Once the container is ready to go, you can run the import tool: You can also use the GridDB Cloud CLI Tool to import: Now that we have And once the code is compiled, you need to set up your database parameters as your environment variables, and then from there, run the code:<\/p>\n Running the sample code will run all of the java code, which includes connections to both JDBC and the NoSQL Interface. Here’s a quick breakdown of the Java Sample files included with this repo:<\/p>\n For the python code, you will need to first install the Python client. There are good instructions found in the docs page: https:\/\/docs.griddb.net\/gettingstarted\/python.html<\/a>. The following instructions are for debian-based systems:<\/p>\n And once installed, you will need to have the Once you’ve got everything done, you will need your creds set up in your environment variables, similar to the Java section above. And from there, you can run the code:<\/p>\n The GridDB Web API is one of the methods of orchestrating your CRUD methods for your GridDB Cloud instance. Prior to this release, the method of authenticating your HTTP Requests to your GridDB Cloud was solely using something called Before I get into how to work the Bearer token into your work flow, I will showcase a simple example of why I asked an LLM to put together a quick demo of a server reading your user and password combo. The LLM produced a server and a client; the client sends its user:pass as part of its headers and the server is able to intercept those and decode and store the user:pass in plaintext! After that, we send another request with a bearer token, and though the server can still read and intercept that, bearer tokens will naturally expire and won’t potentially expose your password which may be used in other apps or anything else. Here is the output of the server:<\/p>\n I think this example is clear, sending your password in every request can cause major leakage of your secret data. This is bad!<\/p>\n As shown in the example above, a Bearer token is attached to the requests’s header, similar to the Basic Auth method, but it’s labeled as such ( This assumes you are familiar with GridDB Cloud in general and how to use the Web API. If you are not, please read the quickstart: GridDB Cloud Quickstart<\/a>.<\/p>\n To be issued an auth token from GridDB Cloud, you must use the web api endpoint: https:\/\/[cloud-id]griddb.com\/griddb\/v2\/[cluster-name]\/authenticate. You make a POST Request to that address with the body being your web api credentials (username, password). If successful, you will receive a JSON response with the access token string (the string you attach with your requests), and an expiry date of that token. From that point on, you can use that bearer token in all of your requests until it expires. Here’s a CURL example:<\/p>\nAzure Resources to Create Virtual Network Peering Connection<\/h4>\n
![\"\"](\"\/wp-content\/uploads\/2025\/11\/create-virtual-network.png\")
<\/a><\/p>\n![\"\"](\"\/wp-content\/uploads\/2025\/11\/create-virtual-macine-with-vnet.png\")
<\/a>><\/p>\nGridDB Cloud — Forging Virtual Network Peering Connection<\/h4>\n
![\"\"](\"\/wp-content\/uploads\/2025\/11\/create-peering-connection.png\")
<\/a><\/p>\n\n
\n
\n
Using the Virtual Network Peering Connection<\/h3>\n
![\"\"](\"\/wp-content\/uploads\/2025\/11\/Provider.png\")
<\/a><\/p>\ntelnet<\/code> to see if the machine is reachable. For example, download the json file, find the transaction address and port number, and then run telnet:<\/p>\n$ wget [notifification-provider-url]\n$ cat mfcloud2102.json\n\n {\n \"cluster\": {\"address\":\"172.26.30.69\", \"port\":10010},\n \"sync\": {\"address\":\"172.26.30.69\", \"port\":10020},\n \"system\": {\"address\":\"172.26.30.69\", \"port\":10040},\n \"transaction\": {\"address\":\"172.26.30.69\", \"port\":10001},\n \"sql\": {\"address\":\"172.26.30.69\", \"port\":20001}\n },\n\n$ telnet 172.26.30.69 10001<\/code><\/pre>\n<\/div>\nSample Code<\/h3>\n
csv<\/code> dataset from Kaggle: https:\/\/www.kaggle.com\/code\/chaozhuang\/iot-telemetry-sensor-data-analysis. We have included the csv<\/code> file with this repo.<\/p>\nIngesting IoT Telemetry Data<\/h4>\n
griddbCloudDataImport<\/code> dir inside of this repository. Within this dir, you will find that the GridDB Cloud Import tool<\/a> is already installed. To use, open up the .sh<\/code> file and edit lines 34-36 to include your credentials. Next, you must run the python file within this directory to clean up the data, namely changing the timestamp column to better adhere to the Web API’s standard, and also to separate out the csv into 3 distinct csv files, one for each device found in the dataset.<\/p>\ndf['ts'] = pd.to_datetime(df['ts'], unit='s').dt.strftime('%Y-%m-%dT%H:%M:%S.%f').str[:-3] + 'Z'<\/code><\/p>\n\"2020-07-12T00:01:34.385Z\"<\/code> so that it can be ingested using the tool. The data which is supplied directly in the CSV before transformation looks like this: \"1.5945120943859746E9\"<\/code>.<\/p>\nschema.json<\/code> file in the directory.<\/p>\n{\n \"container\": \"device1\",\n \"containerType\": \"TIME_SERIES\",\n \"columnSet\": [\n {\n \"columnName\": \"ts\",\n \"type\": \"timestamp\",\n \"notNull\": true\n },\n {\n \"columnName\": \"co\",\n \"type\": \"double\",\n \"notNull\": false\n },\n {\n \"columnName\": \"humidity\",\n \"type\": \"double\",\n \"notNull\": false\n },\n {\n \"columnName\": \"light\",\n \"type\": \"bool\",\n \"notNull\": false\n },\n {\n \"columnName\": \"lpg\",\n \"type\": \"double\",\n \"notNull\": false\n },\n {\n \"columnName\": \"motion\",\n \"type\": \"bool\",\n \"notNull\": false\n },\n {\n \"columnName\": \"smoke\",\n \"type\": \"double\",\n \"notNull\": false\n },\n {\n \"columnName\": \"temp\",\n \"type\": \"double\",\n \"notNull\": false\n }\n ],\n \"rowKeySet\": [\n \"ts\"\n ]\n}<\/code><\/pre>\n<\/div>\n$ griddb-cloud-cli create schema.json<\/code>. If using the UI, simply follow the UI prompts and follow the schema as shown here. Name the container device1<\/code>.<\/p>\n$ .\/griddbCloudDataImport.sh device1 device1.csv<\/code>.<\/p>\n$ griddb-cloud-cli ingest device1.csv<\/code>.<\/p>\nRunning The Sample Code (Java)<\/h4>\n
device1<\/code> defined and populated with data, let’s try running our sample code.<\/p>\n\n$ cd sample-code\/java\n$ export JAVA_HOME=\/Library\/Java\/JavaVirtualMachines\/jdk-23.jdk\/Contents\/Home\n$ mvn clean package<\/code><\/pre>\n<\/div>\nexport GRIDDB_NOTIFICATION_PROVIDER=\"[notification-provider-address]\"\nexport GRIDDB_CLUSTER_NAME=\"[clustername]\"\nexport GRIDDB_USERNAME=\"[username]\"\nexport GRIDDB_PASSWORD=\"[password]\"\nexport GRIDDB_DATABASE=\"[database name]\" <\/code><\/pre>\n<\/div>\n$ java -jar target\/java-samples-1.0-SNAPSHOT-jar-with-dependencies.jar <\/code><\/pre>\n<\/div>\n\n
App.java<\/code> simply runs the main function and all of the methods within the individual classes.<\/li>\nDevice.java<\/code> is the class schema for the dataset we ingest<\/li>\nGridDB.java<\/code> is the NoSQL interface, connecting, creating tables, and querying from the dataset ingested above. The code also shows multiput, multiget, and various aggregation, time sampling etc examples.<\/li>\nGridDBJdb.java<\/code> shows connecting to GridDB via the JDBC interface and also shows creating a table and querying a table. Also shows a GROUP BY RANGE SQL query.<\/li>\n<\/ul>\nRunning The Sample Code (Python)<\/h4>\n
sudo apt install default-jdk\nexport JAVA_HOME=\/usr\/lib\/jvm\/java-11-openjdk-amd64\ngit clone https:\/\/github.com\/griddb\/python_client.git\ncd python_client\/java\nmvn install\ncd ..\ncd python\npython3.12 -m pip install .\ncd ..<\/code><\/pre>\n<\/div>\n.jar<\/code> files in your $CLASSPATH<\/code>. To make it easy, we hve included the jars inside of the lib dir inside the python dir and a script to add the variables to your classpath:<\/p>\n$ source .\/set-env.sh\n$ echo $CLASSPATH<\/code><\/pre>\n<\/div>\n$ python3.12 main.py<\/code><\/pre>\n<\/div>\nWeb API (Basic Authentication vs. Bearer Tokens)<\/h2>\n
Basic Authentication<\/code>, which is the method of attaching your Username and Password to each web request paired with an IP filtering firewall. Though this method was enough to keep things secure up until now, the GridDB team’s release of utilizing Web Tokens greatly bolsters the safety in authentication strategy for GridDB Cloud.<\/p>\nThe Dangers of Basic Authentication<\/h3>\n
Basic Authentication<\/code> can be problematic and lead to issues down the line. Sending your user\/pass credentials in every request leaves you extremely vulnerable to man-in-the-middle attacks. Not only that, but there’s issues with sometimes servers keeping logs of all headers incoming into it, meaning your user:pass combo could potentially be stored in plaintext somewhere on some server. If you share passwords at all, your entire online presense could be compromised.<\/p>\ngo run server.go\nSmarter attacker server listening on http:\/\/localhost:8080\n\n--- NEW REQUEST RECEIVED ---\nAuthorization Header: Basic TXlVc2VybmFtZTpNeVN1cGVyU2VjcmV0UGFzc3dvcmQxMjM=\n\n!!! \u00f0\u009f\u0098\u00b1 BASIC AUTH INTERCEPTED !!!\n!!! DECODED: MyUsername:MySuperSecretPassword123\n\n\n--- NEW REQUEST RECEIVED ---\nAuthorization Header: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJpc3JhZWwiLCJleHAiOjE3NjE3NjA3NjZ9.fake_signature_part<\/code><\/pre>\n<\/div>\nBearer Tokens<\/h3>\n
Bearer<\/code>) and the code itself is a string that must be decoded and decrypted by the server. And though, as explaiend above, you do face a similar threat of somebody stealing your bearer token and being able to impersonate you, this damage is mitigated because the bearer token expires within an hour and doesn’t potentially leak information outside of the scope of this database; not to mention, a bearer token can have granular scopes to make limit damage even further. You can read more about them here, as we wrote about saving these into GridDB here:<\/p>\n\n
How to use with GridDB Cloud<\/h4>\n