Last time, we looked at how you can use a CryptoAPI-backed key as a service account and use it to authenticate. Now let’s see how you can do the same with CNG. Continue »
Using service account keys to authenticate a service account is generally discouraged on Google Cloud, but sometimes difficult to avoid. The most common way to use service account keys is to create a new key by using the Cloud Console or gcloud, but you can also upload existing keys, including CryptoAPI-based keys. Continue »
When you create an enterprise app in Azure AD and configure SAML-based single sign-on, Azure AD assumes that the application also supports SAML for sign-out – but as it turns out, not all apps do. Continue »
When working with cloud services, you occasionally encounter two APIs that essentially do the same thing, but require different authentication or permissions. Such cases tend to pique my interest. Continue »
By default, access to the Compute Engine metadata server is not limited to specific processes or users on a VM, even low-privilege processes can request service account credentials. Can we limit metadata server access to specific Windows users or processes? Continue »
Service accounts play a key role in Google Cloud IAM, but they are easy to get wrong. If you’re not careful, you quickly end up with over-permissioned service accounts, accounts that are used across multiple applications, and service account keys being spread all across your environment. Continue »
What happens if you use the “Set Windows password” function on a domain controller? Continue »
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? Continue »
When you authenticate a user by using OpenID Connect and request the
email_verified, what does this claim indicate and how does Google populate it?
If your plan is to develop a tool or desktop app instead of a server-side application, the benefits of application default credentials are less obvious and reusing the user’s personal gcloud credentials instead might seem attractive. But there are some pitfalls. Continue »
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. Continue »
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…
Once you’ve signed in on google.com, the Cloud Console, or any other Google site, your browser session remains valid for multiple days. Not being prompted to sign in over and over again is convenient and at least in typical consumer scenarios, the risk that comes along with keeping the session is limited.
Things can look different in a corporate scenario where users might have access to sensitive data. Keeping sessions alive for 14 days (which is the default) might seem a little risky and might not be in line with an enterprise’s idea of security. G Suite Business and Cloud Identity Premium therefore allow you to change the default session length to a different period such as 8 hours. This setting applies to all Google services, not only GCP.
Recently, Google introduced another way to control session lifetime by allowing you to control the session length for Cloud Console and gcloud sessions.Continue »
The three main new features in this release are:
- A managed implementation of Cloud IAP TCP tunneling
- OAuth-based authorization.
- Support for custom GCP session lengths.
In the last post, we discussed that each request that Cloud IAP passes to a backend appliation contains a
X-Goog-Iap-Jwt-Assertion header. This header contains an IAP JWT assertion that looks a bit like an IdToken, but is not an IdToken.
Conceptually, you can think of Cloud IAP as a reverse proxy that is deployed in front of your corporate application that intercepts all requests to perform authentication and authorization. Continue »
At Google Cloud, we run a series of Cloud Summits each year. A Cloud Summit is essentially a mini-version of Cloud NEXT – it lasts one day, features multiple tracks of technical sessions, and is usually held in a location where there is plenty of space for booths where customers can ask questions.
One question that we frequently get at the Ask an Architect or Ask the Expert booth is about Cloud Identity-Aware Proxy - what is it for, how does it work, and how to use it?
In this series of blog posts, I am going to address these questions, one at a time:
- Part 1: What is it for? – The role of Cloud IAP in zero-trust (this post)
- Part 2: How does it work? – Cloud IAP architecture
- Part 3: How to use it – Integrating with Cloud IAP