As a cloud architect, I’ve seen more teams lean into Infrastructure as Code (IaC) to manage their data platforms, and AWS Redshift is no exception. With Terraform, you can spin up entire Redshift environments, configure VPC networking, IAM roles, and security groups, and even automate user/role creation.

But this post isn’t just a dry walk-through. I’ll show you how to wire it all up and then share a few fun Redshift features I stumbled across that might make your SQL life more enjoyable (or at least more tolerable).

Why Use Terraform with Redshift?

AWS Redshift is powerful, but the console setup process is… less than ideal. Terraform fixes that.

Benefits of Terraforming Redshift:

Repeatability: One config file to rule them all. Version control: Track changes in Git. Modularity: Use reusable Terraform modules to deploy clusters in dev, staging, or prod. Security: Define IAM roles and permissions declaratively, without manual error.

Quickstart: Provisioning a Redshift Cluster

Here’s a super basic example:provider "aws" { region = "us-east-1" } resource "aws_redshift_cluster" "main" { cluster_identifier = "my-redshift-cluster" database_name = "analytics" master_username = "admin" master_password = "YourSecurePassword1" node_type = "dc2.large" cluster_type = "single-node" publicly_accessible = false iam_roles = [aws_iam_role.redshift_role.arn] } resource "aws_iam_role" "redshift_role" { name = "redshift-role" assume_role_policy = jsonencode({ Version = "2012-10-17", Statement = [{ Action = "sts:AssumeRole", Effect = "Allow", Principal = { Service = "redshift.amazonaws.com" } }] }) }

This gets you a one-node cluster with IAM integration. From here, you can bolt on everything from VPC routing to monitoring and logging.

Terraform + SQL = A Beautiful Workflow

Once your cluster is live, it’s time to automate SQL scripts too. Use local-exec or integrate your Terraform pipeline with something like Flyway, Liquibase, or just a simple script that runs psql or Redshift Data API commands after provisioning.

Fun Redshift/PostgreSQL Functions

Terraform is great, but let’s not forget why you’re here—SQL wizardry.

Here are a few Redshift functions or features that are surprisingly useful (and occasionally delightful):

1. LISTAGG – String Aggregation in a Single RowSELECT department, LISTAGG(employee_name, ', ') WITHIN GROUP (ORDER BY employee_name) AS team FROM employees GROUP BY department;

Great for showing comma-separated team members by department.

2. GENERATE_SERIES – Fake Data for Free

Redshift doesn’t support this natively like Postgres, but you can emulate it:WITH RECURSIVE series(n) AS ( SELECT 1 UNION ALL SELECT n + 1 FROM series WHERE n < 100 ) SELECT * FROM series;

Useful for faking time ranges, populating calendars, etc.

3. PERCENTILE_CONT – Smooth Distribution MetricsSELECT PERCENTILE_CONT(0.5) WITHIN GROUP (ORDER BY salary) AS median_salary FROM employees;

Yes, you can finally stop explaining why AVG() isn’t the same as the median.

4. STL_SCAN & SVL_QUERY_REPORT – Query-Level Insight

Want to know how Redshift is scanning your data? These internal system views are gold for optimization.

Wrap Up

Terraform lets you take control of Redshift the same way you manage EC2, S3, or RDS. It’s scriptable, testable, and repeatable—which is exactly what you want when managing a data warehouse that powers business decisions.

And once you’re live, remember: Redshift has a few SQL tricks up its sleeve. Dig into its PostgreSQL heritage, and you’ll find some gems that make analytics more fun—or at least more tolerable at 3 AM when you’re debugging a query.

If you’re already Terraforming Redshift and have a favorite function or optimization tip, drop it in the comments. Or better yet—let’s turn it into a module.

This is what I will be up to today

While Snowflake provides strong default security capabilities, enterprises must take additional steps to lock down the identity and access layer to prevent unauthorized data access. In this article, we focus on front-end hardening, including authentication mechanisms, federated identity controls, network access constraints, and token lifecycle management. The goal is to ensure that only the right identities, coming from the right paths, under the right conditions, ever reach Snowflake.

Snowflake supports SAML 2.0 and OAuth 2.0-based SSO. You should disable native Snowflake usernames/passwords entirely for production accounts.

SAML (Okta, Azure AD, Ping)

• Create an enterprise application in your IdP.
• Configure SAML assertions to pass custom attributes like role, email, department.
• Use SCIM provisioning to sync Snowflake users/roles/groups from the IdP.
• Set the session timeout in your IdP lower than Snowflake’s to avoid dangling sessions.

Avoid provisioning ACCOUNTADMIN via SAML. Manage this break-glass account separately.

Use EXTERNAL_OAUTH instead of SAML for modern applications or service integrations.

---

Lock Down OAuth Access

Snowflake supports OAuth for both interactive and non-interactive use. You must restrict token scope, audience, and expiration windows to reduce risk.

Key Hardening Strategies:

• Use short-lived tokens (preferably < 15 minutes) for all automation.
• Configure audience (aud) and scopes strictly. Avoid issuing tokens with SESSION:ALL unless required.
• Rotate client secrets for OAuth apps regularly.
• For client credentials flow, ensure the client cannot impersonate high-privileged roles.
• Deny ACCOUNTADMIN access through any OAuth app.

Supported Scopes Examples:

Scope	Description
session:role:<role_name>	Restrict token to one role only
session:warehouse:<wh>	Bind session to specific warehouse

Snowflake OAuth Token Validation (under the hood)

sqlCopyEditSELECT SYSTEM$EXTRACT_OAUTH_TOKEN_CLAIM('aud', '<access_token>');

---

Restrict Native Auth with Network Policies

Even if federated auth is enforced, native logins can still exist and be exploited. Use Snowflake Network Policies to harden this path.

Strategy:

• Create two network policies:
  • admin_policy: Only allows break-glass IP ranges
  • default_policy: Allows enterprise proxy or VPN egress IPs only
• Apply the default to the account:

sqlCopyEditALTER ACCOUNT SET NETWORK_POLICY = default_policy;

• Apply admin_policy only to named break-glass users.

Consider a Cloudflare or Zscaler front-door to enforce geo/IP conditions dynamically.

---

Implement Role Hierarchy Discipline

Identity hardening isn’t complete without strict RBAC practices. Prevent role escalation and sprawl.

Best Practices:

• Disallow use of SET ROLE = ANY unless strictly required.
• Disable PUBLIC role from having any privileges:

sqlCopyEditREVOKE ALL PRIVILEGES ON DATABASE <db> FROM ROLE PUBLIC;

• Ensure OAuth apps assume dedicated roles, not shared ones.
• Create role chains with the principle of least privilege — don’t nest high-priv roles into commonly used ones.

---

Enable MFA Everywhere You Can

Snowflake itself doesn’t natively enforce MFA — this must be handled at the IdP or via authentication proxy.

Solutions:

• Require MFA on all interactive IdP logins (Okta, Azure, Ping).
• Use conditional access policies to block access if MFA isn’t passed.
• For break-glass accounts: Use hardware token MFA or a privileged access broker like CyberArk.

---

Monitor and Rotate OAuth Secrets & Certificates

Snowflake OAuth integrations (especially EXTERNAL_OAUTH) rely on JWT signing keys.

Operational Controls:

• Rotate JWT signing certs every 90 days.
• Monitor for expired or invalid tokens using:

sqlCopyEditSHOW INTEGRATIONS;

• Alert on integration usage via LOGIN_HISTORY or EVENT_HISTORY.

---

Harden Service Account Behavior

Service identities are often the weakest link. Use automation to provision/deprovision service roles and tokenize all secrets via a secrets manager like Vault.

Key Points:

• Never let a service identity own SECURITYADMIN or ACCOUNTADMIN.
• Tag tokens via session:user_agent, session:client_ip and audit the usage patterns.
• For zero trust, bind each service to its own network segment and OAuth flow.

---

Monitor Everything at the Edge

Don’t trust Snowflake alone for auditing — bring data into your SIEM.

Ingest from:

• LOGIN_HISTORY
• QUERY_HISTORY
• ACCESS_HISTORY
• EVENT_HISTORY

Pipe into Splunk, Snowflake, or S3 via Snowpipe and monitor:

• Role switching anomalies
• Login attempts outside normal hours
• OAuth token usage per integration

In an age where cybersecurity threats are relentless and disinformation moves faster than truth, we need leaders who are brave enough to speak facts—even when it’s inconvenient. Chris Krebs, the former director of the Cybersecurity and Infrastructure Security Agency (CISA), has been that kind of leader from day one.

Krebs didn’t seek fame. He didn’t seek a fight. He sought the truth.

As director of CISA, he led one of the most critical missions in modern government: protecting the integrity of U.S. elections and critical infrastructure. Under his leadership, CISA declared the 2020 election “the most secure in American history”—a statement backed by career security experts, intelligence assessments, and hard data.

That statement, grounded in evidence, got him fired.

And now, years later, in a deeply concerning escalation, the current administration has reportedly revoked his security clearance and ordered an investigation into his work at CISA. Let’s be clear—this isn’t about security. It’s about political revenge.

Krebs has since continued to serve the public good, both as co-founder of the Krebs Stamos Group and in his role at SentinelOne. He remains one of the few voices in the field who speaks plainly, refuses to bend to political pressure, and puts the country before career.

If we want to live in a world where facts matter, where professionals are empowered to do the right thing, and where public servants don’t fear retaliation for speaking truth, then we must stand by Chris Krebs.

This isn’t about party. It’s about principle.

We owe our respect—and our support—to those who prioritize the safety of the country over the safety of their own jobs. Krebs did exactly that.

And we should all be damn grateful he did.

Creating the perfect PowerPoint presentation is an art—an equilibrium between compelling content and striking visuals. However, for professionals and developers who need to test the efficiency of co-authoring tools or presentation software, the content itself can sometimes be secondary to the functionality being tested. That’s where the power of automation comes in, particularly in generating mock data for PowerPoint presentations.

I’ve been working on a fun side project It’s a script that allows users to create ‘fake’ PowerPoint data to simulate various scenarios and test how long it takes to read through the content in a process akin to co-authoring. For those intrigued by how this automation operates and its potential benefits, you can delve into the details on my GitHub repository.

Why Automate PowerPoint Data Generation?

The reasons for automating data generation are numerous, especially in a corporate or development setting:

• Testing Efficiency: For software developers and IT professionals, having a tool that automatically generates data can significantly aid in testing the efficiency of co-authoring tools and other collaborative features in presentation software.
• Training: Automated mock presentations can serve as training material for new employees, helping them get acquainted with presentation tools and company-specific templates.
• Benchmarking: By standardizing the length and complexity of the generated content, teams can benchmark the performance of their software or the productivity of their staff.

How Does the Automation Work?

The automation script I developed is designed to be intuitive. It populates PowerPoint slides with random text, images, and data. The script takes into account different factors like text length and complexity, mimicking real-world presentations without the need for manual data entry.

Moreover, I incorporated a timing mechanism to assess how long a ‘co-authoring’ read-through would take. This feature is invaluable for software developers who aim to improve the collaborative aspects of presentation tool

It is up now on my github

As someone who hasn’t been using Terraform for years, something things I’m about to say are obvious to you, someone who likely already knows that it’s a powerful infrastructure-as-code (IAC) tool that allows you to automate the provisioning and management of your cloud resources. With Terraform, you can define your infrastructure using a declarative language, and then use that definition to create, update, and destroy your resources in a consistent and repeatable way.

It has been a fantastic tool to get to know. Most fun I’ve had in technology in a long time.

One of the key benefits of using Terraform is that it allows you to abstract away the complexity of the underlying cloud APIs and services. Instead of having to write custom scripts or manually configure each individual resource, you can define your infrastructure in a high-level, human-readable format that can be version-controlled and shared with your team. This makes it easier to collaborate, track changes, and ensure consistency across your infrastructure.

Terraform also provides a number of built-in features and plugins that make it easy to work with a wide range of cloud providers, services, and tools. For example, you can use Terraform to provision infrastructure on AWS, Azure, Google Cloud, and many other cloud providers. Additionally, Terraform supports a wide range of resource types, including compute instances, load balancers, databases, and more.

Another benefit of using Terraform is that it allows you to automate your infrastructure changes with confidence. Because Terraform is declarative, you can see exactly what changes will be made to your infrastructure before you apply them. This helps you avoid unexpected changes and ensures that your infrastructure remains stable and secure.

Terraform is a fantastic tool for automating your infrastructure and managing your cloud resources. Whether you’re working on a small project or a large-scale enterprise deployment, Terraform can help you achieve your goals quickly and efficiently.

I often wonder why haven’t more companies rolled out DKIM at this point as it is clearly a fix for so many phishing/SPAM issues.

DKIM, which stands for DomainKeys Identified Mail, is an email authentication method designed to detect email spoofing and phishing. It works by allowing an organization to attach a digital signature to an email message, which can be validated by the recipient’s email server. DKIM is an important security feature for any organization that sends email, as it helps to prevent fraudulent emails from being delivered to the recipient’s inbox.

In Office365 and Exchange online, not using DKIM can pose several dangers. Here are a few of them:

1. Increased risk of phishing attacks: Phishing attacks are a type of cyber attack that involve tricking users into revealing sensitive information, such as login credentials or credit card details. Without DKIM, it becomes easier for attackers to impersonate legitimate senders and convince recipients to provide their personal information.
2. Increased risk of email spoofing: Email spoofing is when an attacker sends an email that appears to be from a legitimate sender, but is actually from a fraudulent source. DKIM helps to prevent email spoofing by verifying that the email actually came from the sender’s domain. Without DKIM, it becomes easier for attackers to impersonate legitimate senders and deceive recipients.
3. Increased risk of email interception: Email interception is when an attacker intercepts an email in transit and reads its contents. Without DKIM, it becomes easier for attackers to intercept and read emails, as there is no digital signature to validate the authenticity of the email.
4. Decreased email deliverability: Many email providers, including O365, use DKIM as a factor in their spam filtering algorithms. Without DKIM, emails may be more likely to be flagged as spam or rejected by the recipient’s email server, resulting in decreased email deliverability.

Not using DKIM in O365 can pose several dangers, including increased risk of phishing attacks and email spoofing, increased risk of email interception, and decreased email deliverability. Therefore, it is highly recommended that organizations use DKIM to help ensure the security and authenticity of their email communications.