Merge pull request #19 from brancz/prepare-0.4

Prepare 0.4

CHANGELOG.md

@@ -1,3 +1,10 @@
+## Next release
+
+* [CHANGE] The config file flag has been renamed to `--config-file`.
+* [CHANGE] There is a breaking change in the configuration. All configuration that was previously valid, is now nested in `.authorization.resourceAttributes`.
+* [FEATURE] Add OIDC token authentication provider (note: this is not a client code flow for client authentication).
+* [FEATURE] Add ability to rewrite SubjectAccessReviews based on request query parameters.
+
 ## 0.3.1 / 2018-06-20
 
 This release is unmodified code from v0.3.0, but built with latest golang.

Dockerfile

@@ -5,6 +5,7 @@ COPY . .
 RUN make build
 
 FROM alpine:3.8
+RUN apk add -U --no-cache ca-certificates && rm -rf /var/cache/apk/*
 COPY --from=build /go/src/github.com/brancz/kube-rbac-proxy/_output/linux/amd64/kube-rbac-proxy .
 ENTRYPOINT ["./kube-rbac-proxy"]
 EXPOSE 8080

README.md

@@ -13,13 +13,14 @@ In Kubernetes clusters without NetworkPolicies any Pod can perform requests to e
 The kube-rbac-proxy has all [`glog`](https://github.com/golang/glog) flags for logging purposes. To use the kube-rbac-proxy there are a few flags you may want to set:
 
 * `--upstream`: This is the upstream you want to proxy to.
-* `--resource-attributes-file`: This file specifies details on the SubjectAccessReview you want to be performed on a request. For example, this could contain that an entity performing a request has to be allowed to perform a `get` on the Deployment called `my-frontend-app`.
+* `--config-file`: This file specifies details on the SubjectAccessReview you want to be performed on a request. For example, this could contain that an entity performing a request has to be allowed to perform a `get` on the Deployment called `my-frontend-app`, as well as the ability to configure whether SubjectAccessReviews are rewritten based on requests.
 
 See the `examples/` directory for the following examples:
 
 * [non-resource-url example](examples/non-resource-url)
 * [resource-attributes example](examples/resource-attributes)
 * [oidc example](examples/oidc)
+* [rewriting SubjectAccessReviews based on request query parameters](examples/rewrites)
 
 All command line flags:
 
@@ -33,6 +34,7 @@ Usage of _output/linux/amd64/kube-rbac-proxy:
       --auth-header-groups-field-separator string   The separator string used for concatenating multiple group names in a groups header field's value (default "|")
       --auth-header-user-field-name string          The name of the field inside a http(2) request header to tell the upstream server about the user's name (default "x-remote-user")
       --client-ca-file string                       If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate.
+      --config-file string                          Configuration file to configure kube-rbac-proxy.
       --insecure-listen-address string              The address the kube-rbac-proxy HTTP server should listen on.
       --kubeconfig string                           Path to a kubeconfig file, specifying how to connect to the API server. If unset, in-cluster configuration will be used
       --log_backtrace_at traceLocation              when logging hits line file:N, emit a stack trace (default :0)
@@ -45,7 +47,6 @@ Usage of _output/linux/amd64/kube-rbac-proxy:
       --oidc-issuer string                          The URL of the OpenID issuer, only HTTPS scheme will be accepted. If set, it will be used to verify the OIDC JSON Web Token (JWT).
       --oidc-sign-alg stringArray                   Supported signing algorithms, default RS256 (default [RS256])
       --oidc-username-claim string                  Identifier of the user in JWT claim, by default set to 'email' (default "email")
-      --resource-attributes-file string             File spec of attributes-record to use for SubjectAccessReview. If unspecified, requests will attempted to be verified through non-resource-url attributes in the SubjectAccessReview.
       --secure-listen-address string                The address the kube-rbac-proxy HTTPs server should listen on.
       --stderrthreshold severity                    logs at or above this threshold go to stderr (default 2)
       --tls-cert-file string                        File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert)
@@ -101,4 +102,3 @@ Additionally, to my knowledge Envoy neither has nor plans Kubernetes specific RB
 PR are more than welcome!
 
 * Tests
-* OIDC support

examples/non-resource-url/README.md

@@ -96,12 +96,12 @@ Once the prometheus-example-app is up and running, we can test it. In order to t
 The Dockerfile of this container can be found [here](../example-client/Dockerfile).
 
 ```bash
-$ kubectl create -f client.yaml
+$ kubectl create -f client-rbac.yaml client.yaml
 ```
 
 The content of this manifest is:
 
-[embedmd]:# (./client.yaml)
+[embedmd]:# (./client-rbac.yaml)
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRole
@@ -123,7 +123,10 @@ subjects:
 - kind: ServiceAccount
   name: default
   namespace: default
----
+```
+
+[embedmd]:# (./client.yaml)
+```yaml
 apiVersion: batch/v1
 kind: Job
 metadata:

examples/non-resource-url/client-rbac.yaml

@@ -0,0 +1,20 @@
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: metrics
+rules:
+- nonResourceURLs: ["/metrics"]
+  verbs: ["get"]
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRoleBinding
+metadata:
+  name: metrics
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: metrics
+subjects:
+- kind: ServiceAccount
+  name: default
+  namespace: default

examples/non-resource-url/client.yaml

@@ -1,24 +1,3 @@
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRole
-metadata:
-  name: metrics
-rules:
-- nonResourceURLs: ["/metrics"]
-  verbs: ["get"]
----
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRoleBinding
-metadata:
-  name: metrics
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: metrics
-subjects:
-- kind: ServiceAccount
-  name: default
-  namespace: default
----
 apiVersion: batch/v1
 kind: Job
 metadata:

examples/oidc/.gitignore

@@ -0,0 +1,3 @@
+ssl
+dex-tls-ca-secret.yaml
+dex-tls-secret.yaml

examples/oidc/README.md

@@ -6,7 +6,6 @@ Kubernetes supports OIDC authentication natively, configured via API server flag
 
 If Kubernetes is not configured to use OIDC and changes to the API server are not possible (i.e. in 3rd party or restricted environments), kube-rbac-proxy can be configured to authenticate the request against OIDC itself. In this case, the token review functionality of Kubernetes is omitted. As above the resulting metadata is still passed to the subject review Kubernetes API for authorization.
 
-
 Like in other examples, `kube-rbac-proxy` also requires RBAC access to perform SubjectAccessReviews.
 
 ```bash
@@ -17,7 +16,7 @@ $ kubectl create -f configmap.yaml
 ```
 
 ```bash
-$ kubectl create -f client.yaml
+$ kubectl create -f client-rbac.yaml
 ```
 
 Note: The {ISSUER} and {CLIENT_ID} in the deployment have to be replaced with the issuer and client in the OIDC provider configuration.

examples/oidc/client.yaml → examples/oidc/client-rbac.yaml

@@ -1,13 +1,10 @@
-# Cluster viewer role
----
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRole
 metadata:
   name: metrics
 rules:
 - nonResourceURLs: ["/metrics"]
-  verbs: ["get", "list"]  
-
+  verbs: ["get", "list"]
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRoleBinding
@@ -21,4 +18,4 @@ roleRef:
 subjects:
 - kind: User
   name: admin
-  apiGroup: rbac.authorization.k8s.io  
+  apiGroup: rbac.authorization.k8s.io

examples/oidc/deployment.yaml

@@ -30,12 +30,6 @@ rules:
   resources:
   - subjectaccessreviews
   verbs: ["create"]
-- apiGroups: ["", "apps", "extensions", "rbac.authorization.k8s.io"]
-  resources: ["*"]
-  verbs: ["*"]
-- apiGroups: ["apiextensions.k8s.io"]
-  resources: ["customresourcedefinitions"]
-  verbs: ["get", "list"]
 ---
 apiVersion: v1
 kind: Service

examples/resource-attributes/README.md

@@ -4,7 +4,7 @@
 
 RBAC differentiates in two types, that need to be authorized, resources and non-resoruces. A resource request authorization, could for example be, that a requesting entity needs to be authorized to perform the `get` action on a particular Kubernetes Deployment.
 
-Take the following example. We want to deploy a [prometheus-example-app](https://github.com/brancz/prometheus-example-app), and protect it with the kube-rbac-proxy. In this example we require a requesting entity to be allowed to call the `proxy` subresource on a Kubernetes Service called `kube-rbac-proxy`. This is configured in the file passed to the kube-rbac-proxy with the `--resource-attributes-file` flag. Additionally the `--upstream` flag has to be set to configure the application that should be proxied to on successful authentication as well as authorization.
+Take the following example. We want to deploy a [prometheus-example-app](https://github.com/brancz/prometheus-example-app), and protect it with the kube-rbac-proxy. In this example we require a requesting entity to be allowed to call the `proxy` subresource on a Kubernetes Service called `kube-rbac-proxy`. This is configured in the file passed to the kube-rbac-proxy with the `--config-file` flag. Additionally the `--upstream` flag has to be set to configure the application that should be proxied to on successful authentication as well as authorization.
 
 The kube-rbac-proxy itself also requires RBAC access, in order to perform TokenReviews as well as SubjectAccessReviews. These are the APIs available from the Kubernetes API to authenticate and then validate the authorization of an entity.
 
@@ -67,12 +67,14 @@ kind: ConfigMap
 metadata:
   name: kube-rbac-proxy
 data:
-  resource-attributes.yaml: |+
-    namespace: default
-    apiVersion: v1
-    resource: services
-    subresource: proxy
-    name: kube-rbac-proxy
+  config-file.yaml: |+
+    authorization:
+      resourceAttributes:
+        namespace: default
+        apiVersion: v1
+        resource: services
+        subresource: proxy
+        name: kube-rbac-proxy
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
@@ -92,7 +94,7 @@ spec:
         args:
         - "--secure-listen-address=0.0.0.0:8443"
         - "--upstream=http://127.0.0.1:8081/"
-        - "--resource-attributes-file=/etc/kube-rbac-proxy/resource-attributes.yaml"
+        - "--config-file=/etc/kube-rbac-proxy/config-file.yaml"
         - "--logtostderr=true"
         - "--v=10"
         ports:
@@ -116,12 +118,12 @@ Once the prometheus-example-app is up and running, we can test it. In order to t
 The Dockerfile of this container can be found [here](../example-client/Dockerfile).
 
 ```bash
-$ kubectl create -f client.yaml
+$ kubectl create -f client-rbac.yaml client.yaml
 ```
 
 The content of this manifest is:
 
-[embedmd]:# (./client.yaml)
+[embedmd]:# (./client-rbac.yaml)
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRole
@@ -144,7 +146,10 @@ subjects:
 - kind: ServiceAccount
   name: default
   namespace: default
----
+```
+
+[embedmd]:# (./client.yaml)
+```yaml
 apiVersion: batch/v1
 kind: Job
 metadata:

examples/resource-attributes/client-rbac.yaml

@@ -0,0 +1,21 @@
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: kube-rbac-proxy-client
+rules:
+- apiGroups: [""]
+  resources: ["services/proxy"]
+  verbs: ["get"]
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRoleBinding
+metadata:
+  name: kube-rbac-proxy-client
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: kube-rbac-proxy-client
+subjects:
+- kind: ServiceAccount
+  name: default
+  namespace: default

examples/resource-attributes/client.yaml

@@ -1,25 +1,3 @@
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRole
-metadata:
-  name: kube-rbac-proxy-client
-rules:
-- apiGroups: [""]
-  resources: ["services/proxy"]
-  verbs: ["get"]
----
-apiVersion: rbac.authorization.k8s.io/v1beta1
-kind: ClusterRoleBinding
-metadata:
-  name: kube-rbac-proxy-client
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: kube-rbac-proxy-client
-subjects:
-- kind: ServiceAccount
-  name: default
-  namespace: default
----
 apiVersion: batch/v1
 kind: Job
 metadata:

examples/resource-attributes/deployment.yaml

@@ -49,12 +49,14 @@ kind: ConfigMap
 metadata:
   name: kube-rbac-proxy
 data:
-  resource-attributes.yaml: |+
-    namespace: default
-    apiVersion: v1
-    resource: services
-    subresource: proxy
-    name: kube-rbac-proxy
+  config-file.yaml: |+
+    authorization:
+      resourceAttributes:
+        namespace: default
+        apiVersion: v1
+        resource: services
+        subresource: proxy
+        name: kube-rbac-proxy
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
@@ -74,7 +76,7 @@ spec:
         args:
         - "--secure-listen-address=0.0.0.0:8443"
         - "--upstream=http://127.0.0.1:8081/"
-        - "--resource-attributes-file=/etc/kube-rbac-proxy/resource-attributes.yaml"
+        - "--config-file=/etc/kube-rbac-proxy/config-file.yaml"
         - "--logtostderr=true"
         - "--v=10"
         ports: