One caveat, this one will always have an array input, even if it is a single document yaml. But that's actually potentially a benefit (it's another of my proposed solutions to the original problem I raised :smile: )

Wow, I just noticed this PR, great! Thank you very much for implementing it

@benjamin-bergia Note you don't necessarily need to rewrite your policies, you can just have a new package in your policy bundle that translates between old and new:

// new style input
[
    {
        "path": "foo.yaml",
        "contents": {"foo": "bar"}
    },
    {
        "path": "bar.yaml",
        "contents": {"foo": "ban"}
    },
    {
        "path": "bar.yaml",
        "contents": {"foo": "bar"}
    }
]
// equivalent old-style looks like:
{
    "foo.yaml": [{"foo": "bar"}],
    "bar.yaml": [{"foo": "ban"}, {"foo": "bar"}]
}

# Original policy
package policy

deny[msg] {
  input[filename][index].foo == "bar"
  msg := sprintf("Oh no! in %s doc %d foo is equal to bar!", [filename, index])
}

# Wrapper policy
package policyWrapper

retro_input := {
    filename: contents | 
    filename := input[idx].path
    contents := [
	    input[i].contents | 
    	input[i].path == filename
	]
}

deny[msg] {
	data.policy.deny[msg] with input as retro_input
}

warn[msg] {
	data.policy.warn[msg] with input as retro_input
}

Should yield the correct output. See https://play.openpolicyagent.org/p/AG805MXOdD for the example in the sandbox.

So far everything working great for me. One thing I would like (but probably a lot of work) is if we can have it automatically provision connections from AWS Secrets Manager, i.e. List all secrets with a certain filter (based on tags for example).

What would you like to be added:

I'm trying to retrieve the current contexts API url but I have found no convenient way of getting it, kubectl cluster-info displays it but not in a machine readable way (including ANSI color codes that show up regardless of whether a PTY is there). I ended up using the following script to get it:

function get_cluster_api_url {
    local CONTEXT
    local CLUSTER
    CONTEXT=$(kubectl config current-context)
    CLUSTER=$(kubectl config view -o json | jq -r --arg context "${CONTEXT}" '.contexts[] | select(.name == $context) | .context.cluster')
    kubectl config view -o json | jq -r --arg cluster "${CLUSTER}" '.clusters[] | select(.name == $cluster) | .cluster.server'
}

But that is rather verbose, and potentially fragile.

I would like to be able to get this information from kubectl more easily, I can think of a couple of different ways:

1. Give kubectl cluster-info a --output json option
2. Make the information of the current context available through kubectl config current-context --output json

Why is this needed: In our CI/CD pipeline we have a current context set by kops which is an administrator (cluster-admin), and we want to create a store the cluster api uri in a configuration database

Thanks! I read so many --help outputs for different commands but must've missed that option :\

What would you like to be added:

I'm trying to retrieve the current contexts API url but I have found no convenient way of getting it, kubectl cluster-info displays it but not in a machine readable way (including ANSI color codes that show up regardless of whether a PTY is there). I ended up using the following script to get it:

function get_cluster_api_url {
    local CONTEXT
    local CLUSTER
    CONTEXT=$(kubectl config current-context)
    CLUSTER=$(kubectl config view -o json | jq -r --arg context "${CONTEXT}" '.contexts[] | select(.name == $context) | .context.cluster')
    kubectl config view -o json | jq -r --arg cluster "${CLUSTER}" '.clusters[] | select(.name == $cluster) | .cluster.server'
}

But that is rather verbose, and potentially fragile.

I would like to be able to get this information from kubectl more easily, I can think of a couple of different ways:

1. Give kubectl cluster-info a --output json option
2. Make the information of the current context available through kubectl config current-context --output json

Why is this needed: In our CI/CD pipeline we have a current context set by kops which is an administrator (cluster-admin), and we want to create a store the cluster api uri in a configuration database

Hi, unrelated to @colonelpopcorn but I just tested this alpha release and it works great for us. The one little feature I would request is that it would also get host and port from the secret if available (or at least provide the option to have it do so)

Reading the code, I think there are two problem:

1. When creating a resource, it is only granting permissions, and the code does not seem to have any functionality related to revoking implicitly granted permissions
2. When refreshing the schema resource, while the code reads and parses the policies, it doesn't actually do anything with them. Meaning Terraform will only compare previously set state to desired state, with the current state being completely ignored.

Just tested with both role = "public" and role = "" (since postgres seems to store ACLS for public as "" but the same behaviour is shown for both

Terraform Version

Terraform v0.12.24
+ provider.postgresql v1.7.0

Affected Resource(s)

Please list the resources as a list, for example:

• postgresql_schema

Terraform Configuration Files

resource "postgresql_database" "database" {
  for_each = var.databases
  name = each.key
  template = "template1"
  lc_collate = "en_US.UTF-8"
  lc_ctype = "en_US.UTF-8"
}

// Don't allow the public role to create in the public schema
resource "postgresql_schema" "public" {
  for_each = var.databases

  database = each.key
  name = "public"
  policy {
    role = "public"
    create = false
    create_with_grant = false
    usage = false
    usage_with_grant = false
  }
}

Expected Behavior

I'd expect the public role not to have the (default) usage and create permissions on the public schema

Actual Behavior

The public schema still allows any user (with the public role) to use and create tables. Note that setting create and usage to true and applying, followed by setting them back to false and applying again does remove the permissions as expected.

Important Factoids

Running on RDS created Postgres 12.3 instance