Before we start the migration work to support constraints, let's make an official release and publish an image so users are less affected.

We only have a dev tag at the moment:
https://quay.io/repository/open-policy-agent/gatekeeper?tag=latest&tab=tags

There is some work already in progress in the OPA community around supporting user context using LDAP open-policy-agent/opa#938 The done criteria for this project is

Design how user context will be defined in the policy rules
Help making isMember as higher level function in opa with AAD integration

We need docs that explain how people can extend Gatekeeper with their own templates. For example, we need to explain:

• Deny rule semantics
• The structure of the input document
• How to use JSON Schema to define constraint parameter schema
• How to write policies that depend on inventory
• Difference between the raw Rego and template kinds
• How to upstream templates
• How build-to-yaml process works
• How to debug Rego when constraints aren't matching

Suggestion: GK should automatically point to the name of the Constraint Template that caused the deployment to fail, instead of relying on the user to know to provide that information in the Rego in the CT.

Without the user writing a descriptive message in the CT in the rego field themselves, GK does not provide a status message that points to which constraint caused the pod to be rejected.

For example, if this is the Rego written in the CT:

rego: |
  package dumpall

  deny[{"msg": msg}] {
    msg := sprintf("%v", ["bad"])
  }

Then the status message displays admission webhook "validation.gatekeeper.sh" denied the request: bad, providing the user with no information about which constraint stopped the pods from being created.

The message should instead be something like admission webhook "validation.gatekeeper.sh" [CONSTRAINT_TEMPLATE_NAME] denied the request: bad.

Currently the kube-policy-controller uses the http endpoint of OPA service as it is running as a side car
If the webhook is run as a separate POD it is important to use https endpoint of Open Policy agent.

On a failed watch manager restart, the manager is frozen until the template roster changes again, triggering a new restart.

We should have a mechanism to self-heal without nudging.

The policy library includes a collection of reusable policies that a user may choose from and instantiate with given parameters. We need to design how those policies, instances, and parameters are represented and loaded into OPA so it can make an admission control decision.

Per this Tuesday's meeting, I've put together our proposal for what we think an MVP might contain. Link below. Feedback welcome!

https://docs.google.com/document/d/1EPb3zg-hknAK7WqYh96XIXCEXG9mQqr_Cqn8VuEGoLI/edit?usp=sharing

It looks like the manager app no longer listens on port 9876 as specified in the installation instructions as part of the deploy-all.sh. Ref https://github.com/open-policy-agent/gatekeeper/blob/master/deploy/kpc.yaml#L124

A deeper look at the code reveals a default of port 7925 in the addr flag, however this isn't used - https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/standalone/server.go#L16

Finally it looks like the code is listening on the default http and https ports
https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/standalone/server.go#L97-L104
https://github.com/open-policy-agent/gatekeeper/blob/master/pkg/standalone/server.go#L107-L120

What is the correct configuration here? Please update the docs to reflect the decision. As a work-around I simply set the following port to 443 on Ref https://github.com/open-policy-agent/gatekeeper/blob/master/deploy/kpc.yaml#L124

cc @rite2nikhil

As part of the documentation effort, we need to put together a migration guide that OPA users can follow to move from their existing OPA admission policies to gatekeeper. Non-comprehensive list of items to consider:

• Top-level rules to expose (previously users had to implement boilerplate AdmissionReview response rule, now they implement a set of deny rules)
• K8s context layout changes
• Patch vs. deny

We also need to document unsupported features in the MVP like support for arbitrary external context.

Hi,

I'm not sure if it makes sense considering the current scope of the policy manager, but maybe it would be a good idea if the policy manager is also usable as Authorization Module Webhook.

Expected:

{
  "message": "total violations:1",
  "violations": [
    {
      "id": "ingress-host-fqdn",
      "resource": {
        "kind": "ingresses",
        "namespace": "qa",
        "name": "ingress-bad"
      },
      "resolution": {
        "message": "invalid ingress host fqdn \"acmecorp.com\""
      }
    }
  ]
}

Actual:

{
  "message": "total violations:1",
  "violations": [
    {
      "id": "ingress-host-fqdn",
      "resource": {},
      "resolution": {
        "message": "invalid ingress host fqdn \"acmecorp.com\""
      }
    }
  ]
}

reading the documentation it is clear that policies for kubernetes starts with the following:

deny[{
    "type": "always",
    "resource": {"kind": kind, "namespace": namespace, "name": name},
    "resolution": {"message": "test always violate"},
}]

when a policy with that header is run in a unit test it gets an error saying that the kind, namespace and name are not defined. here is a more complete example:

deny[{
	"id": "unreadable secret",
	"resource": {"kind": "secrets", "namespace": "secret_namespace", "name": name},
	"resolution": {"message": "Your're not allowed to see secret in the namespace 'secret_namespace'"},
}] {   
    input.spec.group[_] = "developers"
    input.spec.resourceAttributes.verb = "get"
}

and a test:

package authorization

test_sa_allow {
    not deny with input as {
        "apiVersion": "authorization.k8s.io/v1beta1",
        "kind": "SubjectAccessReview",
        "spec": {
            "resourceAttributes": {
            "namespace": "secret_namespace",
            "verb": "get",
            "group": "core",
            "resource": "secrets",
            "name": "ciao"
            },
            "user": "default",
            "group": [
            "serviceacconts"
            ]
        }
    }
}

If I run this test I get the following error:

1 error occurred: unreadable_secrets.rego:11: rego_unsafe_var_error: var name is unsafe

how can I fix this issue?
Also can you provide a bit of explanation of what is going on from a language syntax perspective? I don't understand what the deny header section really represents.

Thanks
Raffaele

In current design there are two separate calls for validation and mutation. This is not ideal as

1. in some cases the API server will not have proximity with the web hooks (for instance on a public network),
2. validation will fail if the object is not mutated
3. Policy owner and user have to define two separate ruled for validation and mutation

Can the policies be defined in a manner that they more desired state instead of separate mutation and validation policies and mutation can be indirectly inferred ?

Policy are reusable documents and will see contribution from community. Currently these policies are part of this reop in the policy folder and are small in number, but we envision this to be a larger list, Here are some of the thoughts for this

• Have a separate repo of policy
• Have a validation tool and a policy creation too in addition to kubernetes controller validating crd as a admission controller
• Using Helm as the deployment vehicle for policies.
• The other area of this design is how can these policies be installed on the cluster.
  Do we need a service that can install the policies.

Right now it points to MS

Expected Behavior

Installing Gatekeeper on a new v1.14.2 cluster would succeed

Actual Behavior

Installation fails with the following error:

error: SchemaError(io.k8s.api.core.v1.VolumeDevice): invalid object doesn't have additional properties

Steps to Reproduce the Problem

1. Provision a Kind cluster using the latest images:

$ kind create cluster --name gatekeeper --wait 200s
$ export KUBECONFIG=(kind get kubeconfig-path --name="gatekeeper")

2. Install Gatekeeper according to the README instructions:

$ kubectl apply --filename https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper-constraint.yaml
error: SchemaError(io.k8s.api.core.v1.VolumeDevice): invalid object doesn't have additional properties

Note that ignoring validation will install the resources:

$ kubectl apply --validate=false --filename https://raw.githubusercontent.com/open-policy-agent/gatekeeper/master/deploy/gatekeeper-constraint.yaml
namespace "gatekeeper-system" created
clusterrolebinding.rbac.authorization.k8s.io "manager-rolebinding" created
clusterrole.rbac.authorization.k8s.io "manager-role" created
statefulset.apps "gatekeeper-controller-manager" created
service "gatekeeper-controller-manager-service" created
secret "gatekeeper-webhook-server-secret" created
validatingwebhookconfiguration.admissionregistration.k8s.io "validation.gatekeeper.sh" created
customresourcedefinition.apiextensions.k8s.io "constrainttemplates.templates.gatekeeper.sh" created
customresourcedefinition.apiextensions.k8s.io "configs.config.gatekeeper.sh" created

Additional Info

$ kubectl version
Client Version: version.Info{Major:"1", Minor:"10", GitVersion:"v1.10.11", GitCommit:"637c7e288581ee40ab4ca210618a89a555b6e7e9", GitTreeState:"clean", BuildDate:"2018-11-26T14:38:32Z", GoVersion:"go1.9.3", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-17T00:58:35Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}

$ kind version
v0.3.0

Like openpolicyagent/opa and openpolicyagent/kube-mgmt is it possible to release azure policy controller in official Microsoft docker hub repo? It will make it more official for organizations who wants to deploy it as is into there K8s clusters.

Give users a README that allows them to explore the state of the project as-is

kubectl should support a --dry-run option for every mutation to show what it would do, without actually doing it. Integrate Gatekeeper results in --dry-run scenario.

Hi OPA community members. We would like to solicit design proposals from the community for projects that aim to solve the same problem AND/OR function in a similar manner to this project by using OPA to implement desired policy via the Kubernetes API.

The goal is to agree on a design as a community before proceeding with project milestones and/or any further implementation.

Please comment on this issue and attach any design documentation and/or other fodder. We will then review and schedule time for you to present at a community meeting.

@timothyhinrichs will provide further guidance on some areas to include in your proposal.

Feel free to comment should you have any further questions.

cc @timothyhinrichs @tsandall @rite2nikhil @maxsmythe

Trace dumps specified in the Config resource should also provide the option to dump the state of OPA into the logs

something like dump: true/false

Define the e2e test matrix and implement. The design should be such that new scenarios can be added in a repeatable manner (without too much effort)

From the Open Policy Agent documentation, it looks like the policy evaluation model is that there are two main packages for rules and facts: data and input. Policies and facts are stored in the data package and when a new request comes it is passed in the input package.
Kubernetes-policy-controller seems to be taking another approach. It parses the incoming request (whether it is authorization or admission) puts it in the data.kubernetes.type.namespace.name.resource structure.
The request ends up being mixed with the other resources that have been loaded by kube-mgmt.
There is, though, a significant semantic difference between the resources already present in etcd and a request referencing a resource that may or may not exist, so perhaps a separation would be more natural and easy to understand.

Why was it decided not to use the standard approach?

I also believe that the current approach has a flaw, consider this policy:

package admission
import data.k8s.matches

deny[{
	"id": "ceph-name",
	"resource": {
		"kind": kind,
		"namespace": namespace,
		"name": name,
	},
	"resolution": {"message": "You are not allowed to objects with the name `ceph`"}
}] {
	matches[[kind, namespace, name, resource]]
    resource.metadata.name = "ceph"
} 

We want to prevent the admission of any new resource named ceph.

Consider what would happen if we turned this on on a cluster that has already some resources named ceph (assume kube-mgmt is replicating all the resources for simplicity of the model). This policy would always fail, no matter the name of the new resource, a match would always be found....

Here's a modified version of the tutorial constraint template (K8sRequiredLabels) I tried to apply recently that just denies every request:

apiVersion: templates.gatekeeper.sh/v1alpha1
kind: ConstraintTemplate
metadata:
  name: dumpall
spec:
  crd:
    spec:
      names:
        kind: DumpAll
        listKind: DumpAllList
        plural: dumpall
        singular: dumpall
targets:
 - target: admission.k8s.gatekeeper.sh
   rego: |
        package dumpall
        deny[{"msg": msg}] {
           msg := sprintf("%v", [input])
        }

Upon a kubectl apply, the response is:
Error from server (ConstraintTemplate must specify one target): error when creating "ct-test.yaml": admission webhook "validation.gatekeeper.sh" denied the request: ConstraintTemplate must specify one target

This makes sense once I noticed that targets: is indented outside of the spec, but it took quite a while to identify that. Perhaps GK could warn or print a more specific error when it doesn't find a spec.targets in a ConstraintTemplate?

The audit demo in demo/audit.sh no longer works due to #56. How would we like to proceed?

I was thinking we could add port 7925 back to the gatekeeper manifest but I'm not sure it listens on that port based on #53

/cc @rite2nikhil @maxsmythe

Gatekeeper with constraint does not currently handle data sync with opa when there is a resource deletion. As a result, audit result is incorrect as OPA still has the deleted object.

There are two types of policies Deny and Patch which are currently configured as Config Maps and are Posted to OPA, Making policy CRD, This will help prevent deletes of policies on the cluster with CRD using RBAC. The work will be in kube-mgmt which is currently being tracked by open-policy-agent/kube-mgmt#16

Hi OPA community members! We are looking to enlist your help in finding a new name for this project.

Background:
Given that this project has recently been donated to OPA, the project community through it might make for an apt time to rename this project. Other reasons for a rename include verbosity, and project purpose may be a little vague with the current name.

How:
Feel free to make suggestions on this issue based on the following criteria:

English word: No made-up terms or acronyms please. The name should be discoverable in an English dictionary.
Must convey project intent: Please submit constructive names that relate and convey the purpose of this project.

Suggestions from this issue will be tallied and presented before the community meeting before a final decision is made. Please note that final name selection may require legal and other logistical checks.

When
Please submit your ideas BEFORE Monday, Jan. 28th. Thank you!

Thanks!
Credit to @ncdc via vmware-tanzu/velero#1122 for inspiration on renaming process.

👋 thanks for sharing this project. I haven't looked the deployment script into details yet but is there any plan and/or is it possible to get a helm chart for it?

Would like to have a discussion on the build and release process for the project. Currently, there are several areas for which enhancements can be made which will spur additional contribution and overall adoption:

The primary area of concern is that the image in DockerHub has a finite number of tags available and the most recent version is multiple months old and is out of sync.

Areas include:

1. Creation of a release process
   1. Tags in git repository
   2. Tags in image registry
   3. Utilization of a latest tag
2. Formal CI/CD to validate contributions

The proposal is to authz as a separate repo it case use the gatekeeper as a library and continue to use the same policy definitions.

This project has moved to use kube-builder and 'auth' enpoint is really running as a standalone server.

@sbueringer can you please share your thoughts on this issue.

If we want to use freestanding OPA in the future, we will need to periodically reconcile cached constraint/constraint templates to account for the fact that the query engine and its interface may have separate lifecycles.

Users can indicate they want a request to be traced via the Config resource. This should be document

Now that we've got design docs for Gatekeeper as a whole and the policy library, it feels like it's time to start moving that content out of Google docs and into a markdown file in the repository. This document will be useful for people who prefer a "top down" approach to learning about Gatekeeper as well as folks who want to find out more after kicking the tires with the quick start guide.

The initial version of the document should include content from:

• Gatekeeper architecture https://docs.google.com/document/d/1It-Mpz36ygqrElmh2hZ3DvDIqKYyKUZN6V4d7UTlEG8/edit?ts=5c6cd105#

• Policy library design proposal: https://docs.google.com/document/d/1yC4wgpVoJj6ngYnSTtO-HeaIBl05gla562sD7qKPy3M/edit#

The initial version should call out which areas are implemented today versus planned.

Ensures that .sh files retain LF when cloned/checked out via a Windows terminal.

Currently there are two methods supported namely validate and mutate.

This work is to provide a audit method with query parameter to filter on resource, namespace or name (or all (default)).

In addition to get the audit history which use kubernetes api to get the history of audit logs / metrics for all pass/ failed requests.

Note the work will also include the decision to make audit as a separate service from the web-hook (if needed based on performance and customer scenario)

Expected:

apiVersion: v1
kind: Service
metadata:
  labels:
    control-plane: controller-manager
    controller-tools.k8s.io: "1.0"
  name: gatekeeper-controller-manager-service
  namespace: gatekeeper-system
spec:
  selector:
    control-plane: controller-manager
    controller-tools.k8s.io: "1.0"
  ports:
  - port: 443

Actual:

apiVersion: v1
kind: Service
metadata:
  labels:
    control-plane: controller-manager
    controller-tools.k8s.io: "1.0"
  name: gatekeeper-controller-manager-service
  namespace: gatekeeper-system
spec:
  ports:
  - port: 443

Results in error:

failed calling webhook "mutation.styra.com": Post https://gatekeeper-controller-manager-service.gatekeeper-system.svc:443/v1/admit?timeout=30s: dial tcp 10.0.69.83:443: connect: connection refused

We should automate the building/bundling of the Rego source for TargetHandler.

This would make sure that our Rego unit tests are more useful by removing the possibility of copy/paste errors.

We need to document the getting started process with the new model. The getting started guide should cover how users can:

1. Install Gatekeeper in a Kubernetes cluster
2. Discover templates available on the cluster
3. Instantiate a constraint from a template
4. Exercise the constraint via kubectl

Once users have completed the basic steps above they could be guided through the process of creating a new template for a common scenario and then running audit on the cluster to detect violations.

kubernetes-policy-controller as Admission controller uses OPA server as the policy engine backend. The work item is to add liveness and readiness probes to check the health of OPA server

by convention, secret containing certificates in kubernetes should be of type "kubernetes.io/tls"
also the entries should be:

• tls.key
• tls.crt
• ca.crt
  compliance helps interoperability with other certificate generation systems, such as for example cert-manager

Ref: #42

Community decided on the rename of this project to gatekeeper

cc @tsandall

Started documenting audit design proposal @maxsmythe @tsandall

We need to explain how people can manage Gatekeeper installations. Some things that come to mind:

• How do you install and upgrade Gatekeeper (gotchas?)
• How do you secure Gatekeeper itself?
• RBAC configuration required to replicate K8s objects into OPA
• How do you monitor Gatekeeper performance?
• Debug FAQ for common problems (webhook misconfigured, network issues, logs, etc.)
• How are webhook certificates provisioned (this is handled by kube-builder but that's an implementation detail from the admin's POV so we should cover it.)

We should clean up the ignoring of constraint-not-recognized errors by creating a special error type to avoid using string matching

For Namespace awareness/exclusion, similar to label selector, can Gatekeeper support NamespaceSelector for constraints.

https://gist.github.com/ritazh/19d1d1a7d36a3d57c8bbc127c36a93ea#namespace-awarenessexclusion

We should have "integration" tests that allow us to verify that our piping of resources to matchers is working appropriately. Currently any bug in src.rego would not be caught by unit tests.

Currently if there is a Rego compilation error with a ConstraintTemplate, the error reporting oscillates.

This is due to the update after the createCRD() call not being inside the if statement, meaning the resource gets written whether there is an error or not: