Use a Terraform template to deploy a Monitoring instance with Sysdig and configure for container-based access control for metrics and dashboards.

In the “Sustainable and Scaleable Access Control with Sysdig Teams” post, the IBM Cloud Monitoring team provided a good introduction to Sysdig Teams and the value brought to disparate teams that might be sharing a Sysdig instance for their metrics and dashboards.   

This post will explore the scenario in which two separate development teams are sharing the same Monitoring instance and the same IBM Cloud Kubernetes Service, and it will demonstrate how a team can automate the process of deploying and configuring such an environment. 

Deployment scenario


Two development teams are working on a complex application that will eventually be deployed on the same Kubernetes cluster. To provide for a more elaborate example, let’s assume that each team has selected their preferred programming language—in this case, Go and Node.js. Once their applications are ready—or as they go through various iterations of it—they create a container image and publish it to a private container registry in the IBM Cloud.  

An infrastructure team is responsible for deploying the environment (i.e., Kubernetes cluster), Monitoring with Sysdig, and configuring the access levels to the metrics and dashboards. They choose to use Terraform, an Infrastructure-as-Code tool used on previous projects. All the resources and applications will be deployed in an IBM Cloud region. Identity and Access Management will be used to assign access to the Monitoring instance and restrict who can see what metrics.

Deploying and configuring the components

This repository contains all the infrastructure configuration instructions to create and configure the resources as depicted above. Here is a high-level overview of the code repository structure. Follow the instructions and use the template provided on Github:


  • The main.tf contains the instructions for setting up the Terraform provisions used for this template. 
  • The instance_config.tf contains the instructions for creating and configuring the Monitoring with Sysdig instance. It will also create the teams and assign the filtering to limit access to metrics based on the container tags. 
  • The agent_install.tf contains the instructions to deploy the Sysdig agent to the Kubernetes cluster. 
  • The app_install.tf contains the instructions to deploy the applications from the container registry to the Kubernetes cluster. 
  • The variables.tf contain all of the input required by the Terraform template. Don’t modify this file, as the number of values that you need to modify is more limited. Use the config.tfvars to supply your values as described in the repository.  
  • The scripts folder contains the various shell scripts that are invoked during the run of the Terraform template. As of this writing, the Sysdig provider for Terraform does not provide resources to create teams in Sysdig Monitor, therefore the above script is used to create the Sysdig team leveraging the Sysdig REST APIs. A change is coming soon to add support for this capability in the provider and will be reflected in the repository. 

After deploying the environment, in the Monitoring instance, the Infrastructure Engineer has a complete view of all metrics from the Kubernetes cluster. 

View from the Infrastructure Engineer standpoint.

The Node.js and Go developers see the metrics that are of interest to them, respectively:

View from the Node.js Developer standpoint.

View from the Go Developer standpoint.

Getting started

To get started, try our sample code on GitHub. Instructions are provided to create and use the template. We will start with creating a Kubernetes cluster via the IBM Cloud UI or CLI and then apply the template to create the Sysdig instance and the IAM policies. We also cover how to clean up resources when you no longer need them.  

Questions and feedback 

The GitHub repository for this scenario has an Issues tab where you can comment on the content and code. If you have suggestions or issues, please submit your feedback.

More from Cloud

Clients can strengthen defenses for their data with IBM Storage Defender, now generally available

2 min read - We are excited to inform our clients and partners that IBM Storage Defender, part of our IBM Storage for Data Resilience portfolio, is now generally available. Enterprise clients worldwide continue to grapple with a threat landscape that is constantly evolving. Bad actors are moving faster than ever and are causing more lasting damage to data. According to an IBM report, cyberattacks like ransomware that used to take months to fully deploy can now take as little as four days. Cybercriminals…

2 min read

Integrating data center support: Lower costs and decrease downtime with your support strategy

3 min read - As organizations and their data centers embrace hybrid cloud deployments, they have a rapidly growing number of vendors and workloads in their IT environments. The proliferation of these vendors leads to numerous issues and challenges that overburden IT staff, impede clients’ core business innovations and development, and complicate the support and operation of these environments.  Couple that with the CIO’s priorities to improve IT environment availability, security and privacy posture, performance, and the TCO, and you now have a challenge…

3 min read

Using advanced scan settings in the IBM Cloud Security and Compliance Center

5 min read - Customers and users want the ability to schedule scans at the timing of their choice and receive alerts when issues arise, and we’re happy to make a few announcements in this area today: Scan frequency: Until recently, the IBM Cloud® Security and Compliance Center would scan resources every 24 hours, by default, on all of the attachments in an account. With this release, users can continue to run daily scans—which is the recommended option—but they also have the option for…

5 min read

Modernizing child support enforcement with IBM and AWS

7 min read - With 68% of child support enforcement (CSE) systems aging, most state agencies are currently modernizing them or preparing to modernize. More than 20% of families and children are supported by these systems, and with the current constituents of these systems becoming more consumer technology-centric, the use of antiquated technology systems is archaic and unsustainable. At this point, families expect state agencies to have a modern, efficient child support system. The following are some factors driving these states to pursue modernization:…

7 min read