Workload identity federation isn’t limited to authenticating workloads between cloud providers. There are many other scenarios where it can be useful to use workload identity federation instead of service account keys. Not all platforms or services support workload identity federation, but it’s not too difficult to change that.
Continue »
Whenever we want to call a Google or Google Cloud API, we need an access token. But there’s more than one way to obtain an access token, and depending on which way we use, the resulting access token might behave a little differently. What kinds of access tokens are there, and how do they differ?
Continue »
With the latest version of Just-in-Time access, we can now demand that users seek approval from a peer before they can activate certain roles.
Continue »
When an on-premises application needs to access Google Cloud, it’s tempting to just let it use a service account key. But if the application runs in an Active Directory environment, there’s a better alternative – we can let it use its domain credentials and “exchange” them against Google credentials. That doesn’t even require custom code anymore.
Continue »
With Just-in-Time Access, we can implement just-in-time privileged access management on Google Cloud by allowing users to temporarily elevate their access to certain projects. But a key limitation of the initial release of JIT Access was that it didn’t support inherited role bindings. Version 1.1 removes this limitation and features a new UI.
Continue »
Any call we make against a Google API is charged against a project quota. Depending on the API that we’re using, that project quota might limit the frequency of calls, the total number of calls, or even the number of calls per user. But which project’s quota is it that’s being charged?
Continue »
To implement role-based access control to Google Cloud resources, it’s often useful to create a set of groups, where each group represents a role for a certain set of resources. But how can we automate the management of these groups, without granting our automation too much access?
Continue »
When developing applications that use the Google Cloud API, being able to trace and inspect HTTP requests with a tool like Fiddler can be a great debugging aid. But getting Fiddler to work with the Java client libraries can be a bit tricky.
Continue »
The first thing we often do after creating a new Windows VM on Google Cloud is join the VM to Active Directory. With the latest IAP Desktop release, that got a little easier.
Continue »
When we use a tool like gcloud or IAP Desktop for the first time, we need to authorize it. Google Sign-in then shows us a consent screen that lists all the things the tool might do on our behalf, and we can decide whether to consent or deny. But sometimes, we get a third option.
Continue »
When we run License Tracker for the first time, the tool analyzes the last 90 days of audit logs to determine how many VMs and physical servers we’ve been using. Going back 90 days in history is useful, but can we go back further?
Continue »
When we bring our own Windows licenses to Google Cloud, we must keep track of the number of physical servers that we’re using those licenses on. By using sole-tenant nodes, we can control which nodes our VMs run on, but nodes aren’t the same as physical servers.
Continue »
To deploy software or infrastructure automatically, many deployment pipelines need access to Google Cloud, so we let the pipelines use a service account. The more we rely on deployment pipelines and their service accounts, the more extensive and privileged their access to Google Cloud can become. And that creates new risks.
Continue »
Libssh2 lets us choose between multiple different crypto backends. But that doesn’t mean these backends are interchangeable – there are also some functional differences.
Continue »
Secure LDAP is a Cloud Identity feature that lets it emulate an LDAP server. From an application’s perspective, Secure LDAP makes Cloud Identity look somewhat similar to Active Directory – but authentication works a little differently.
Continue »
AWS lets us use access keys to authenticate programmatically. That’s useful for local development, or if we want to let tools access AWS on our behalf. The closest thing to access keys on Google Cloud seem to be service account keys. But are they really that similar?
Continue »
The principle of least privilege states that we should grant users just enough access to carry out everyday activities, but no more. But what about the occasional case where a user does need privileged access, maybe to handle an incident or perform a rare configuration change? This is where just-in-time access can help.
Continue »
When we allow users to use SSH to connect to Linux VMs on Google Cloud, we need to keep track of their public keys, and which VMs they have access to. The latest version of IAP Desktop makes that a little easier.
Continue »
Before we deploy an application to Google Cloud, we typically want to test it locally. If the application uses Google Cloud APIs, then we somehow need to ensure that the application can authenticate. We could use a service account key for that, but there’s typically a better way.
Continue »
Extending a platform or service to support workload identity federation
