profile
viewpoint

gwkunze/Structr 42

Define, validate and process PHP datastructures

gwkunze/S3StreamWrapper 22

A PHP Stream wrapper for Amazon S3

gwkunze/dynamo-session-bundle 13

DynamoDb Session Handler for Symfony 2

gwkunze/IpAddress 9

PHP IP address handling library

gwkunze/assetic 1

Asset Management for PHP 5.3

gwkunze/api-test 0

Repository to contain some test commits / issues to help test github api client

gwkunze/authenticator 0

A tool for using AWS IAM credentials to authenticate to a Kubernetes cluster

gwkunze/aws-cli 0

Universal Command Line Interface for Amazon Web Services

gwkunze/aws-sdk-php 0

Official repository of the AWS SDK for PHP. For more information on the AWS SDK for PHP, see our web site:

gwkunze/conftest 0

Write tests against structured configuration data using the Open Policy Agent Rego query language

pull request commentopen-policy-agent/conftest

Combine configurations into struct when using combine

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: )

jpreese

comment created time in 2 days

pull request commentopen-policy-agent/conftest

Combine configurations into struct when using combine

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.

jpreese

comment created time in 2 days

issue commentaws/aws-toolkit-jetbrains

Datagrip - Connect to RDS instances with AWS secrets manager

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).

colonelpopcorn

comment created time in 15 days

issue closedkubernetes/kubectl

Retrieve Kubernetes API uri for current context

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

closed time in 2 months

gwkunze

issue commentkubernetes/kubectl

Retrieve Kubernetes API uri for current context

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

gwkunze

comment created time in 2 months

issue openedkubernetes/kubectl

Retrieve Kubernetes API uri for current context

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

created time in 2 months

issue commentaws/aws-toolkit-jetbrains

Datagrip - Connect to RDS instances with AWS secrets manager

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)

colonelpopcorn

comment created time in 2 months

issue commentterraform-providers/terraform-provider-postgresql

Revoking public schema access not working as expected

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.
gwkunze

comment created time in 2 months

issue commentterraform-providers/terraform-provider-postgresql

Revoking public schema access not working as expected

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

gwkunze

comment created time in 2 months

issue openedterraform-providers/terraform-provider-postgresql

Revoking public schema access not working as expected

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

created time in 2 months

startedspotify/backstage

started time in 3 months

more