Create new resource: postgresql_grant

[cyrilgdn]

This resource allows to grant privileges on all existing tables or sequences for a specified role in a specified schema.

This fix #29

Example:

resource postgresql_grant "readonly_tables" {
  database    = "test_db"
  role        = "test_role"
  schema      = "public"
  object_type = "table"
  privileges  = ["SELECT"]
}

Hi there (cc @apparentlymart ),

We started to use this provider to manage our Postgresql databases/credentials. As its current state is quite buggy and there's several useful resources missing, we started to develop it to adapt to our needs.

We saw that the Terraform team at HashiCorp does not develop on it anymore and there's also multiple open PRs so I'm not even sure you are able to take time to review/merge community PRs.

We'll open all our PRs anyway so, in the worst case, it could at least be useful to other people with the same needs.

Thanks.

[Nyrraven]

+1

[lentferj]

+1

[philippfe]

+1

[paulojmdias]

+1

[guilhermeblanco]

+1

[olib963]

@cyrilgdn I was just wondering what your thought on integrating schema grants with this would be?

Example:

resource postgresql_grant "admin_schema_access" {
  database    = "test_db"
  role        = "test_role"
  schema      = "test_schema"
  object_type = "schema"
  privileges  = ["ALL"]
}

This would allow us separation between schema and grants whereas the current implementation requires grants for a schema to be tied directly to that schema.

[cyrilgdn]

@olib963 Yes it was in my plan for this resource to manage other entity types. But we just wanted to do it step by step to make smaller PR in order to be merged easier.

Furthermore, as you said, it's already possible to configure policies for schema in the postgresql_schema resource (even if I also find it not very convenient and if, after some tests, policies deletion is a bit buggy) so this will need to remove all this code and I think it's really better to create a separate PR for this case.

I'm waiting for an answer from Hashicorp about the futur of this provider and hope we'll be able soon to merge PRs and release new versions with all these new features.

[sean-]

@cyrilgdn I thought about this more and I would be okay with this if you changed the implementation so the prefix of every permission has a +. Something like:

+SELECT or +UPDATE, etc

The reason being this would allow for an implementation that sets the absolute permissions, an additive/composable set of permissions, or an ACL blacklist:

For example:

• -SELECT = Remove the SELECT permission from an object (i.e. ensure the resource doesn't have SELECT perms)
• SELECT = the only permission that is set is SELECT
• +SELECT = Add the SELECT permission to an object (i.e. ensure the resource has at least the SELECT permission)

@cyrilgdn what do you think of that? The implication here, if I understood the implementation correctly (it's also been a few weeks since I read the code so I forget the details, but that's the high-bit in my memory).

[cyrilgdn]

@sean- Thanks for your answer !

To be honest, I don't really get this blacklist reflexion. Do you have a specific use case for that?

I don't see a case where you want to add a privilege to a user without knowing what other privileges he has. And if you want to remove a privilege, you can describe what this user should have.
For me I see a postgresql_grant resource like: "Here are the privileges applied on these tables for this user"
(That's how I see Terraform, a way to describe the state of your infra). Otherwise you don't really know in which state is your database and it's error-prone.

But if additive/composable permission is really a wanted feature, I can try to work on it but I think this does not prevent to merge these 2 PRs (#51 and #53) as they already implement absolute permissions and several people seemed interested.

Also, if I had to implement relative permissions, I think I would prefer have multiple fields, like the current privileges one stays for absolute permissions and we could create add_privileges and revoke_privileges (better names are welcome) which are both in conflict with privileges.
It avoids the need to manage errors with value like ["SELECT", "+INSERT"] and I find it more explicit.

My two cents.

[cyrilgdn]

@sean- Any update on this ? Do you think we can merge these PRs anyway? And I can try to work on relative privileges in other PRs if needed.

If someone else has an opinion to share on this, feel free !

[evgmoskalenko]

@cyrilgdn, Hello, tell me please, when the release is expected?

[blalor]

This looks really great! I was surprised to find that a resource for managing grants didn't already exist.

I agree that managing a differential set of grants seems to run counter to The Terraform Way™. @sean- can you provide examples of where this is done in other providers?

[cyrilgdn]

I close this PR in favor of #53 which depends on this one anyway (and as it's hard to maintain both and hard to find reviewers)