After creating a Windows VM on Google Cloud, users can use the Cloud Console or IAP Desktop to request login credentials. But what are the risks of letting users generate credentials, and is there a way to prevent them from doing so?
When you authenticate a user by using OpenID Connect and request the email scope, most identity providers add two additional claims to the ID Token, email and email_verified. The email claim does not need much explanation – but what about email_verified, what does this claim indicate and how does Google populate it?
When you create a VM instance on Google Cloud, you can optionally specify instance metadata. Instance metadata is a list of key/value pairs and the most common use case for using metadata is passing a startup or shutdown script to a VM. But startup and shutdown scripts are not the only platform features that rely on metadata.
One of the less well known features of Google Cloud Shell is that it has PowerShell preinstalled. All it takes to convert your Cloud Shell session into a PowerShell session is to run a single command.
In the last post, we looked at the risks of using local port forwarding and how it’s difficult to protect TCP tunnels in a multi-user environment. In this post, we take a look at how IAP Desktop protects its tunnels.
In a company’s journey to the cloud, one of the topics that is important to sort out early is identity management. To do anything meaningful with Google Cloud, employees need to be able to sign in to the Cloud Console – but manually creating user accounts for each employee is rarely a good idea.
Azure DevOps has come a long way since its humble beginnings as Visual Studio Team System. Especially its CI/CD component, Azure Pipelines, has made some major leaps over the past years and is now actually quite nice to use.
gcloud manages two sets of credentials, your personal credentials and application default credentials. Having two separate credentials might seem redundant and can cause surprises the first time you use one of the Google Cloud client libraries. But the two credentials serve different purposes.
Google APIs use OAuth 2.0 for authentication and authorization. To call an API, you first have to obtain an access token for the right scope and then pass it to the respective API by using the Authorization HTTP header.
But the trouble with access tokens is that they are short-lived, and you somehow have to deal with expiring tokens…
A bit over 12 years ago I started this blog to write about Windows development. Back then,
I spent the majority of both my free time and time at work developing Win32 and COM-based software
and I was just starting to tip my toes into Kernel-mode development.
Things got quiet after 2010 when I changed careers and begun working as a consultant.
My focus shifted from Windows development to architecting scalable systems and later led
me to entirely different topics such as leading development teams and optimizing the software development lifecycle.
Although I never stopped doing Windows development, it got less over time – and I had less to write about
on this blog.
Now it is about time to get more active again on this blog. And as a first step,
I moved this blog to a new home.
Quite obviously, Google does not always get it right either. Ever when I try to see my Google Calendar (using Opera), I am requested to login. So I enter my credentials, am redirected a couple of times and – are broght to the login page again. Logging in again does not help, I have by then entered an infinite loop. Thankfully, I can escape this loop by jumping to the original calendar URL again – now Google recognizes that I have already logged in and shows me my calendar.