Ir al contenido principal

Defining Google Cloud IAM conditions for Secret Manager roles

Defining conditions for the permissions granted to a Google Cloud service account helps to enforce our security policy. By defining conditions we can, for instance, specify not just that a given account can access to secrets, but also to what secrets.

This is really important since, in case an attacker could take control of a compute resource associated to an account with read access to secrets, he would literally be able to read all our secrets. However, if a condition is applied to that permission, just the secrets matching the condition would be exposed.

In order to define an IAM permission condition, it is necessary to access to the Google Cloud IAM administration console and editing the principal (service account) whose permissions must be conditioned.

Then by clicking the "ADD CONDITION" label of the role whose permissions must be conditioned, we access to the condition definition view, that contains both the Condition Builder that allows us defining conditions based on a visual interface, and the Condition Editor that allows the same but by writing CEL expressions.

Specifically, the CEL expression for restricting the access to a given secret is:

resource.name == "projects/<project number>/secrets/<secret name>/versions/latest"

... where <project number> is the number of our Google Cloud project and <secret name> is the name of the secret whose access is restricted by the condition (the number of our Google Cloud project can be obtained by running the gcloud CLI command gcloud projects list).

Therefore, the CEL expression matching a secret called MY_SECRET in a project with project number 1234567890 would be:

resource.name == "projects/1234567890/secrets/MY_SECRET/versions/latest"

CEL also allows simplifying the above definition by just checking the latest part of a resouce name, what is useful in case of not having (or not wanting to set) the project number. In that case, the expression would be:

resource.name.endsWith("/secrets/<secret name>/versions/latest")
Etiquetas:

Comentarios

Publicar un comentario

Entradas populares de este blog

Linting C# in Visual Studio Code

Though very usual in programming environments as Javascript/Typescript, linting , or analyzing code for enforcing a set of coding style rules, is not usually present in the .NET based environments. Rule enforcing is really useful when working on team shared codebases in order to keep them coherent, what in last term reduces both development times and coding errors. A linting example Maybe a practical example would be helpful for explaining what  linting  is to the newcomers (feel free to go on if you aren't). Let's imagine you are a new member in a C# development team that has well established set of coding style rules. Instead (or apart) of putting them in a document, they've adopted a tool that checks these rules during the code building process. Your first code is such ambitious as this: namespace HelloWorld {      using System;      public class Program      {           public static void Main(string[] args)           {                Console
Publicar un comentario
Leer más

ESlint: Ignore unused underscore variables

Some naming conventions promote the use of the underscore character (" _ ") for those variables that must be declared but are not being used. One common case is that in which a function signature contains some variables that will not be used, as for instance the Express error handlers: app.use(function(err, req, res, next) { console.error(err.stack); res.status(500).send('Something broke!'); }); In the above example only the arguments err and res are being used, though all four must be defined in the handler signature. Thus, following the naming convention of using underscores for those unused variables, we could recode it as: app.use(function(err, _, res, __) { console.error(err.stack); res.status(500).send('Something broke!'); }); Though it makes the function more readable, it comes with a problem if using ESlint: it will blame by declaring unused variables. error '_' is defined but never used error '__' is define
Publicar un comentario
Leer más

Using Bitbucket app passwords with git on MacOS (OSX)

Learn how Bitbucket passwords are stored by git on MacOS.
Publicar un comentario
Leer más