This clears itself up in the next reconcile cycle, but we should add some code to ensure a resource is fully deleted before trying to recreate it.

It'd be convenient if rbac-manager created service accounts that didn't exist and deleted any that were created by rbac-manager and no longer in the spec.

Hello,
I receive notifications about the new releases but seems the all.yaml file not updated in the deploy directory.
Please update that file as well to correspond to the latest version.

As a follow up to #74 we now see that the new version of rbac-manager seem to try to add some ClusterRoleBinding and RoleBindings twice, which leads to an error in the logs. This happens when we add a user for exmaple.

From looking at the code, I suspect that these roles are existing twice in the parsedClusterRoleBindings but I did not dig deep enough to be sure.

This does not happen when there is only exactly one ClusterRolebinding is defined, but only when there are multiple.

Here are the logs:

time="2019-09-13T06:57:06Z" level=info msg="Reconciling RBACDefinition human-access"
time="2019-09-13T06:57:06Z" level=info msg="Deleting Cluster Role Binding: XXX"
time="2019-09-13T06:57:06Z" level=info msg="Deleting Cluster Role Binding: YYY"
time="2019-09-13T06:57:06Z" level=info msg="Creating Cluster Role Binding: YYY"
time="2019-09-13T06:57:06Z" level=info msg="Creating Cluster Role Binding: YYY"
time="2019-09-13T06:57:06Z" level=info msg="Creating Cluster Role Binding: XXX"
time="2019-09-13T06:57:06Z" level=error msg="Error creating Cluster Role Binding: clusterrolebindings.rbac.authorization.k8s.io \"YYY\" already exists"
time="2019-09-13T06:57:06Z" level=info msg="Creating Cluster Role Binding: XXX"
time="2019-09-13T06:57:06Z" level=error msg="Error creating Cluster Role Binding: clusterrolebindings.rbac.authorization.k8s.io \"XXX\" already exists"
time="2019-09-13T06:57:06Z" level=info msg="Deleting Role Binding ZZZ"
time="2019-09-13T06:57:07Z" level=info msg="Deleting Role Binding AAA"
time="2019-09-13T06:57:07Z" level=info msg="Creating Role Binding: ZZZ"
time="2019-09-13T06:57:07Z" level=info msg="Creating Role Binding: ZZZ"
time="2019-09-13T06:57:07Z" level=info msg="Creating Role Binding: AAA"
time="2019-09-13T06:57:07Z" level=error msg="Error creating Role Binding: rolebindings.rbac.authorization.k8s.io \"ZZZ\" already exists"
time="2019-09-13T06:57:07Z" level=info msg="Creating Role Binding: AAA"
time="2019-09-13T06:57:07Z" level=error msg="Error creating Role Binding: rolebindings.rbac.authorization.k8s.io \"AAA\" already exists"

We've now run into two failure scenarios during rbac-manager's Reconciliation run where it failed to log anything relevant to:

• an error occurred
• a resource could not be created
• following resources in the same RBACDefinition were skipped
• reconciliation terminated, and terminated early.

For example, the log output would end with

$ kubectl logs -n rbac-manager rbac-manager-7b499c48b6-tjzj8
time="2019-08-05T19:37:37Z" level=info msg=----------------------------------
time="2019-08-05T19:37:37Z" level=info msg="rbac-manager 0.7.0 running"
time="2019-08-05T19:37:37Z" level=info msg=----------------------------------
...
time="2019-08-05T19:54:18Z" level=info msg="Reconciling RBACDefinition my-rbac-definition"
$ kubectl ...

And no reference to error scenarios, for example:

• Kubernetes RBAC "Privilege Escalation Prevention" forbids rbac-manager from binding roles when rbac-manager itself does not have the permissions in said role.
  • This case is user error, but took several days to track down due to the lack of warning or error logs from rbac-manager
  • We encountered this when attempting to bind a create-namespace role, but had not granted that permission to rbac-manager.
• rbac-manager fails because no namespaces exist which match a provided namespaceSelector.matchLabels (see #53)

My go fu is limited, but I think the Reconciler itself may have and return a useful err here, but the wrapping code does nothing with it here. Though I'm surprised I was seeing no error output from this code...

Was working on updating rbac-manager and it looks like images are failing to download. I moved back to 0.8.4 and image pull works. Is there a 0.9.0 image?

Back-off pulling image "quay.io/reactiveops/rbac-manager:0.9.0"

are there any plans to enhance this to resolve google groups to the members? so when you search for rob in the examples at https://medium.com/uptime-99/making-sense-of-kubernetes-rbac-and-iam-roles-on-gke-914131b01922, it also resolves the google groups to search for user rob?

Combining the requests of both #99 and #101, it would be very beneficial to end users to have some extended validation of the rbacdefintion. This issue will serve as a proposal and tracking issue for that request.

Things to be validated:

• Namespaces referenced by rbacdefinition currently exist
• Roles/ClusterRoles that are referenced in rbacdefinition currently exist
• ServiceAccounts referenced by rbacdefition do not exists, or if they do, let the user know? Defined by results of #84

In my cluster no ClusterRoleBindings are getting created by rbac-manager when no subject is set.
Also no error is outputted.

RBAC Definition (redacted)

- name: XXX-admins
  subjects:
    - kind: User
      name: 'XXX/[email protected]'
  clusterRoleBindings:
    - clusterRole: cluster-admin
- name: YYY-admins
  subjects:
    - kind: User
      name: 'XXX/[email protected]'
    - kind: User
      name: 'XXX/[email protected]'
  clusterRoleBindings:
    - clusterRole: XXX:customer-admin
  roleBindings:
    - clusterRole: admin
      namespaceSelector:
        matchExpressions:
          - key: customer-system
            operator: NotIn
            values:
              - "true"
- name: ZZZ-users
  subjects: []
  roleBindings:
    - clusterRole: admin
      namespaceSelector:
        matchExpressions:
          - key: customer-system
            operator: NotIn
            values:
              - "true"

Role Bindings

default       XXX-users-YYY-admins-admin   ClusterRole/admin      XXX/[email protected], XXX/[email protected]
default       XXX-users-YYY-users-admin    ClusterRole/admin                                                               
kube-public   XXX-users-YYY-admins-admin   ClusterRole/admin      XXX/[email protected], XXX/[email protected]
kube-public   XXX-users-YYY-users-admin    ClusterRole/admin                                                               
test          XXX-users-YYY-admins-admin   ClusterRole/admin      XXX/[email protected], XXX/[email protected]
test          XXX-users-YYY-users-admin    ClusterRole/admin                                                               

Cluster Role Bindings
No ClusterRoleBindings getting created

Log

time="2019-09-16T15:45:59Z" level=info msg=----------------------------------
time="2019-09-16T15:45:59Z" level=info msg="rbac-manager 0.8.2 running"
time="2019-09-16T15:45:59Z" level=info msg=----------------------------------
time="2019-09-16T15:45:59Z" level=info msg="Registering components"
time="2019-09-16T15:45:59Z" level=info msg="Watching resources related to RBAC Definitions"
time="2019-09-16T15:45:59Z" level=info msg="Watching RBAC Definitions"
time="2019-09-16T15:45:59Z" level=info msg="Reconciling RBACDefinition XXX-users"
time="2019-09-16T15:45:59Z" level=info msg="Reconciling default namespace for XXX-users"
time="2019-09-16T15:45:59Z" level=info msg="Reconciling kube-public namespace for XXX-users"
time="2019-09-16T15:45:59Z" level=info msg="Reconciling kube-system namespace for XXX-users"
time="2019-09-16T15:45:59Z" level=info msg="Reconciling monitoring namespace for XXX-users"
time="2019-09-16T15:46:00Z" level=info msg="Reconciling rbac-manager namespace for XXX-users"
time="2019-09-16T15:46:00Z" level=info msg="Reconciling test namespace for XXX-users"
time="2019-09-16T15:46:00Z" level=info msg="Reconciling cert-manager namespace for XXX-users"

I ran into an issue earlier today where I was deploying a new log collector with a basic service account bound to one cluster role and after I launched the RBACDefinition rbac-manager started to repeatedly create and delete the same Service account

time="2019-12-30T19:22:18Z" level=info msg="Deleting Service Account zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Creating Service Account: zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Deleting Service Account zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Creating Service Account: zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Deleting Service Account zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Creating Service Account: zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Deleting Service Account zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Creating Service Account: zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Deleting Service Account zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Creating Service Account: zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Deleting Service Account zlog-collector"
time="2019-12-30T19:22:18Z" level=info msg="Creating Service Account: zlog-collector"

(this is a snippet, it was doing that endlessly from when I deployed the definition to when I deleted it)

My setup was this:

---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: zlog-collector
  namespace: zlog
rules:
- apiGroups:
  - ""
  resources:
  - namespaces
  - deployments
  - pods
  - events
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: zlog-collector
rbacBindings:
  - name: zlog-collector
    subjects:
      - kind: ServiceAccount
        name: zlog-collector
        namespace: zlog
    clusterRoleBindings:
      - namespace: zlog
        clusterRole: zlog-collector

Any ideas? Tagging @sudermanjr since you seem to run point on these.

We deployed rbac-manager in OpenShift OKD 3.11. When starting the operator, OpenShift complains about user nobody in the Dockerfile.

Error: container has runAsNonRoot and image has non-numeric user (nobody), cannot verify user is non-root

We fixed this by replacing USER nobody with USER 65534 and commenting runAsUser: 1200 in the manifest file

          ...
          securityContext:
          #runAsUser: 1200
          allowPrivilegeEscalation: false
          privileged: false
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          capabilities:
            drop:
              - ALL

in the deploy/all.yaml file.

Hey 👋

It would be nice to be able to match namespaces based on name, not only on labels. Same feature was requested in #47, but it was closed for some reason.

Any thoughts on that, would it be hard to implement?

Thanks!

Upon install with helm chart version 1.5.0 (with rbac-manager version 0.9.1), the logs show constant deleting/creating of service accounts:

time="2020-02-25T17:33:41Z" level=info msg="Creating Service Account: circleci"
rbac-manager-7777d6846-5bcmf rbac-manager time="2020-02-25T17:33:42Z" level=info msg="Deleting Service Account circleci"
rbac-manager-7777d6846-5bcmf rbac-manager time="2020-02-25T17:33:42Z" level=info msg="Creating Service Account: circleci"
rbac-manager-7777d6846-5bcmf rbac-manager time="2020-02-25T17:33:42Z" level=info msg="Deleting Service Account circleci"
rbac-manager-7777d6846-5bcmf rbac-manager time="2020-02-25T17:33:42Z" level=info msg="Creating Service Account: circleci"
rbac-manager-7777d6846-5bcmf rbac-manager fatal error: concurrent map writes

This does not occur with helm chart version 1.4.6 (with rbac-manager version 0.8.3). The issue looks to be in this PR: #100

Scenario:

• a rbacdefinition is created
  • the referenced namespace does not exist
• rbac-manager fails to create rolebinding
  • this is expected
• the namespace is created
  • rbac-manager is not trying to create the rolebinding

time="2019-11-12T15:08:38Z" level=info msg="Creating Role Binding: network-access-network-access-edit"
time="2019-11-12T15:08:38Z" level=error msg="Error creating Role Binding: namespaces \"mynamespace\" not found"

I'd expect rbac-manager to keep trying and recreate the RoleBinding when the namespace has been created.

The log output during startup needs to be updated:
#74 (comment)

It was reported that ClusterRoleBindings currently require namespaces. This should not be the case.

@thejosephstevens, could you please post the rbacdefinition and logging associated with this?

When running the controller loop, the watch is only handling add/update events. Adding delete would complete the cycle and allow full cleanup of resources.

I have a query and just want to know if that is doable with rbac-manager ?

Case1 - Is it possible to define multiple namespaces under one cluster role

I know below config is doable

   - kind: User
    name: bloomreach-bre-deploy-user
roleBindings:
  - clusterRole: admin
    namespace: namespace1
  - clusterRole: admin
    namespace: namespace2

But is it possible to define like below?

   - kind: User
    name: bloomreach-bre-deploy-user
roleBindings:
  - clusterRole: admin
    namespace: namespace1
    namespace: namespace2
    namespace: namespace3

In the the AWS section (https://reactiveops.github.io/rbac-manager/aws.html) the option mapAccounts is mentioned, but with little context. Where must this option be specified?

Add leader election so that we can run more than one pod of rbac-manager.

Case 1 - My requirement is as soon as I add a user in my EKS cluster under aws-auth config map, it should get access to view role without me to add a user in RBAC definition YAML file. Like below is something which will work wherein under I need to add User every time, a new User is added but it is not possible to define wildcard * under User so that I don't have to edit the rbac-definition YAML file ?

kind: RBACDefinition
metadata:
name: rbac-manager-mw-read
rbacBindings:

• name: BAU-DEV-OPS-USERS-ACCESS
  subjects:
  • kind: User
    name: *
    roleBindings:
  • clusterRole: view
    namespaceSelector:
    matchLabels:
    access: mw-global-read

Case2 - Can we add multiple Users under one Kind User? Like shown below

kind: RBACDefinition
metadata:
name: rbac-manager-mw-read
rbacBindings:

• name: BAU-DEV-OPS-USERS-ACCESS
  subjects:
  - kind: User
  name: user1
  name: user2
  name: user3
  roleBindings:
  • clusterRole: view
    namespaceSelector:
    matchLabels:
    access: common

Hey all! About a month ago I ran into a bunch of issues configuring new RBACDefinitions, and it turned out I had some misunderstandings about how RBACDefinitions work (they create their own service accounts), and I was misconfiguring the Definition in certain ways (putting namespaces in the wrong fields, as indicated in issue #86 ).

It would be very helpful if these issues could be surfaced when the RBACDefinition is submitted rather than at runtime. Specifically, if it could check for the existence of a service account and validate that the roles it's looking for exist, that would be very helpful.

Similar to how network policies are implemented, it would be extremely helpful for our use-case if rbac-manager could dynamically create role-bindings in namespaces selected via name and/or a label selector.

We have N number of dynamically provisioned namespaces and we'd like to have rbac definitions applied to all based upon selection criteria, but also have newly added namespaces matching the same criteria be automatically updated.

I'm currently creating namespaces dynamically for ephemeral environments. They all follow a pattern but with some uniqueness, it'd be awesome to be able to match on .*PATTERN.*

I don't think this is currently possible.

cat 1.yaml
apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
name: joe-access
rbacBindings:

• name: joe
  subjects:
  • kind: User
    name: [email protected]
    roleBindings:
  • namespace: api
    clusterRole: view
  • namespace: web
    clusterRole: edit

kubectl apply -f 1.yaml
rbacdefinition.rbacmanager.reactiveops.io/joe-access created

kubectl logs -f -n rbac-manager rbac-manager-696c985976-55kv6
time="2019-11-05T02:21:34Z" level=info msg=----------------------------------
time="2019-11-05T02:21:34Z" level=info msg="rbac-manager 0.8.3 running"
time="2019-11-05T02:21:34Z" level=info msg=----------------------------------
time="2019-11-05T02:21:34Z" level=info msg="Registering components"
time="2019-11-05T02:21:34Z" level=info msg="Watching resources related to RBAC Definitions"
time="2019-11-05T02:21:34Z" level=info msg="Watching RBAC Definitions"
time="2019-11-05T02:26:24Z" level=info msg="Reconciling RBACDefinition joe-access"
time="2019-11-05T02:26:24Z" level=info msg="Creating Role Binding: joe-access-joe-view"
time="2019-11-05T02:26:24Z" level=error msg="Error creating Role Binding: namespaces "api" not found"
time="2019-11-05T02:26:24Z" level=info msg="Creating Role Binding: joe-access-joe-edit"
time="2019-11-05T02:26:24Z" level=error msg="Error creating Role Binding: namespaces "web" not found"

Bug

Description

I tried to deploy this project on my Kubernetes cluster and I can see a memory leak on the latest version (0.7.0). Each 2 minutes, the rbac-manager container take around 6Mb more of RAM.

Context

Version: 0.7.0
Log:

time="2019-07-10T14:30:57Z" level=info msg=----------------------------------
time="2019-07-10T14:30:57Z" level=info msg="rbac-manager 0.7.0 running"
time="2019-07-10T14:30:57Z" level=info msg=----------------------------------
time="2019-07-10T14:30:57Z" level=debug msg="Setting up client for manager"
time="2019-07-10T14:30:57Z" level=debug msg="Setting up manager"
time="2019-07-10T14:30:57Z" level=info msg="Registering components"
time="2019-07-10T14:30:57Z" level=debug msg="Setting up scheme"
time="2019-07-10T14:30:57Z" level=debug msg="Setting up controller"
time="2019-07-10T14:30:57Z" level=info msg="Watching resources related to RBAC Definitions"
time="2019-07-10T14:30:57Z" level=info msg="Watching RBAC Definitions"
time="2019-07-10T14:30:58Z" level=info msg="Reconciling RBACDefinition rbac-definition"
time="2019-07-10T14:30:58Z" level=debug msg="Cluster Role Binding already exists rbac-definition-xxx"
time="2019-07-10T14:30:58Z" level=debug msg="Matches requested Cluster Role Binding: rbac-definition-xxx"

RBACDefinition Kind:

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  creationTimestamp: 2019-07-10T14:00:33Z
  generation: 1
  labels:
    app.kubernetes.io/instance: rbac-definition
    app.kubernetes.io/managed-by: Tiller
    app.kubernetes.io/name: rbac-definition
    helm.sh/chart: rbac-definition-0.1.0
  name: rbac-definition
  resourceVersion: "39790"
  selfLink: /apis/rbacmanager.reactiveops.io/v1beta1/rbacdefinitions/rbac-definition
  uid: 1580e73a-a31b-11e9-b0a7-0e03d92c217e
rbacBindings:
- clusterRoleBindings:
  - clusterRole: cluster-admin
  name: xxx
  subjects:
  - kind: Group
    name: admin

Expected behaviour:

Memory should stay at same level in time if nothing change in cluster.

Thanks !

As per discussion, the chart should be moved to a chart specific repository to follow the standard pattern.

1 If due to any issue or upgrade RBAC-manager pod gets stopped will it impact the role bindings it created?
2 Currently, there is only one Pod of RBAC-Manager that runs, is it possible to run multiple replicas of RBAC-Manager pods? Will it not cause conflict while listening to RBAC Definitions ? If it is doable please let me know what are prod specific recommendations for using RBAC-Manager.

Hey!

Thanks for the great operator!

Discovered bug with 0.6.0 rbac-manager. If CRD contains rbacBindings with only matchExpressions selectors, then that CRD isn't processed during reconcile. If I create new ns with matching labels for matchExpressions – nothing happens, RBAC mgr doesn't create new bindings in newly created ns. If the same match is done via matchLabels – everything works correctly.

for example if I have this CRD submitted to cluster:

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: ns-access
rbacBindings:
  - name: group-a
    subjects:
      - kind: Group
        name: group-a
    roleBindings:
      - clusterRole: edit
        namespaceSelector:
          matchExpressions:
            - {key: group/a, operator: Exists}

Then when created ns with that label:

apiVersion: v1
kind: Namespace
metadata:
  creationTimestamp: "2019-05-02T07:13:44Z"
  labels:
    group/a: ""
  name: test-5
...

RBAC mgr will not evaluate that CRD and thus no bindings will be created there.

On the other side this CRD works fine:

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: ns-access
rbacBindings:
  - name: group-a
    subjects:
      - kind: Group
        name: group-a
    roleBindings:
      - clusterRole: edit
         namespaceSelector:
           matchLabels:
             group/a: ""

add a metrics endpoint to track metrics. Possible options are:

• error count
• number of clusterroles created
• number of service accounts created

This endpoint could also be used to handle liveness probes. See #68 and #69

We test your solution on our k8s cluster v1.16.2.
After applying CRD and RBACDefinition (we copy it from example) in rbac-manager we don't seen any problems:

time="2019-10-18T18:40:33Z" level=info msg="Watching RBAC Definitions"
time="2019-10-21T18:47:15Z" level=info msg="Reconciling RBACDefinition rbacmanager-all-users"

at the same time in logs of kube-apiserver:

E1018 18:47:01 1 customresource_handler.go:655] error building openapi models for rbacdefinitions.rbacmanager.reactiveops.io: SchemaError(io.reactiveops.rbacmanager.v1beta1.RBACDefinition.rbacBindings.roleBindings.namespaceSelector.matchExpressions): array should have exactly one sub-item

As a result is no new role binding created and no any errors in logs of rbac-manager.

Thanks for this operator, it is indeed very handy.

Ran across an issue today where a user within a namespace was able to remove a RoleBinding which is managed by RBACManager, but RBACManager didn't notice and/or repair the binding.

To fix, I had to re-apply the definition. It would be great if RBACManager did some more defensive work to ensure the role bindings that were defined were not tampered with. Especially since I haven't found a good way to protect these generated roles from users who need permissions to manage their own roles in the namespaces.

When

• upgrading to version v0.8.0
• overriding the base manifest deploy file with 0.8.0. (still references 0.7.0)

The liveness probes fail due to "sh" binary missing.

Using rbac-manager v0.8.1

We are running rbac-manager with securityContext.readOnlyRootFilesystem: true in a GKE cluster and when we update the master version or a configuration (of the master), the rbac-manager starts to crashloop with errors :

Unable to decode an event from the watch stream: http2: server sent GOAWAY and closed the connection; LastStreamID=1069, ErrCode=NO_ERROR, debug=""
log: exiting because of error: log: cannot create log: open /tmp/rbac-manager.rbac-manager-66c45f4895-5rwrh.unknownuser.log.ERROR.20191112-084947.1: no such file or directory

We setup a dirty workaround to use an emptyDir for /tmp but that would be nice if rbac-manager could handle connection to the k8s api in a failsafe manner (or if at least it could avoid trying to log to files when an Error occurs)

When working with GKE, you need to create a clusterrolebinding to make your user a cluster admin. A lot of people probably do this step already to get Helm installed, but it might be helpful to have in the docs.

Something like

kubectl create clusterrolebinding your-user-cluster-admin-binding --clusterrole=cluster-admin [email protected]

In rbac-manager 0.8.4 i found that application version still 0.8.3 in "version/version.go"

When rbac-mananger decides to create a serviceaccount, it only allows for imagePullSecrets to be populated or not.

I would like to also be able to set the automountServiceAccountToken attribute. Normally I set this to false in the ServiceAccount and then selectively set it to true in pods that need it.

I envision this being exposed in the CR like so:

---
apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
  name: foo
rbacBindings:
  - name: foo
    subjects:
      - kind: ServiceAccount
        name: foo
        namespace: foo
        automountServiceAccountToken: false
    roleBindings:
      - role: foo

I tried to upgrade from 0.6.1 to 0.8.1.

The pod comes up fine, but the logs contain a lot of errors of the form

time="2019-09-12T16:17:27Z" level=info msg="Creating Role Binding: XXX"
time="2019-09-12T16:17:27Z" level=error msg="Error creating Role Binding: rolebindings.rbac.authorization.k8s.io \"XXX\" already exists"

Therefore changes in the user management do not get applied.

What is the recommended way of upgrading an existing installation of RBAC Manager?

So this software manages bindings of already existing roles but what do you use to create new roles?
Let's say I need to provide users with ability to use port-forward on pods but there is no such clusterrole by default.

Hi,

Just wanted to try rbac-manager, so git cloned master, helm installed, but the deploy fails with:

error: error validating "deploy/all.yaml": error validating data: 
[ValidationError(CustomResourceDefinition.status): missing required field "conditions" in 
io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1beta1.CustomResourceDefinitionStatus, ValidationError(CustomResourceDefinition.status): missing required field "storedVersions" in 
io.k8s.apiextensions-apiserver.pkg.apis.apiextensions.v1beta1.CustomResourceDefinitionStatus]; if you 
choose to ignore these errors, turn validation off with --validate=false

This is what got created so far.

$ kubectl get all -n rbac-manager
NAME                                READY   STATUS    RESTARTS   AGE
pod/rbac-manager-6495d59965-x2w99   1/1     Running   0          4m37s

NAME                           DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/rbac-manager   1         1         1            1           4m37s

NAME                                      DESIRED   CURRENT   READY   AGE
replicaset.apps/rbac-manager-6495d59965   1         1         1       4m37s

Should I ignore the the validation or it's a bug ?

Thank you, this seems like an awesome project!

Service accounts can be given image pull secrets. Support this in the rbacdefinition.

https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account

Requested by @thejosephstevens

Following the addition of matchLabels in #34, it could be great if it can also have the matchExpressions.

It can actualy be really tricky when you need to combine multiple labels which can take multiple values.

Here a concrete exemple

criticality=danger, caution, none
environment=production, staging, qa, uat, development
tier=frontent, backend, cache, database
tenant=departmentA, departmentB, clientA

Now I'm in a situation similar to this one:

departmentA-admins
departmentA-ops
departmentA-devs

departmentB-admins
departmentB-ops
departmentB-devs

clientA-ops
clientA-devs

Some needs to have access to everything with a certain tenant/environment couple, so it's not perfect, but not this painful, for ex, departmentA-ops should have access to all environments except production on frontend tier, that is 4 rules. No if I through in that they can only access to it if criticality is not danger, then it jumps to 8 rules.

And that is not even the worst case I got :)

What if tomorrow I add a beta environment ? I need to add rules everywhere...

With matchExpressions, we only need 1 binding instead of 8 to achieve the same goal:

  matchExpressions:
    - {key: criticality, operator: NotIn, values: [danger]}
    - {key: environment, operator: NotIn, values: [production]}

We don't currently have a known pattern around how to handle pre-existing service accounts. We should test what happens and decide on a defined policy.

I would expect the namespace reconciler to handle the case where an rbac definition is applied that creates a service account in a namespace that doesn't exist yet. However, if I do this and then create the namespace, the serviceaccount never gets created.

Rbacdefinition:

apiVersion: rbacmanager.reactiveops.io/v1beta1
kind: RBACDefinition
metadata:
name: ci-access
rbacBindings:

• name: ci
  subjects:
  • kind: ServiceAccount
    name: ci
    namespace: infra
    roleBindings:
  • clusterRole: cluster-admin
    namespaceSelector:
    matchLabels:
    team: ci-access

Log output from rbac-manager:

rbac-manager-5b796664cf-9fphp rbac-manager time="2019-05-22T14:38:44Z" level=info msg="Watching RBAC Definitions"
rbac-manager-5b796664cf-9fphp rbac-manager time="2019-05-22T14:38:57Z" level=info msg="Reconciling RBACDefinition ci-access"
rbac-manager-5b796664cf-9fphp rbac-manager time="2019-05-22T14:38:57Z" level=info msg="Creating Service Account: ci"
rbac-manager-5b796664cf-9fphp rbac-manager time="2019-05-22T14:38:57Z" level=error msg="Error creating Service Account: namespaces "infra" not found"
rbac-manager-5b796664cf-9fphp rbac-manager time="2019-05-22T14:39:02Z" level=info msg="Reconciling infra namespace for ci-access"

Commands that I issued through this process:

k apply -f rbacdefinition.yaml
k create ns infra

This was done with the latest dev version from this PR - image dev-b00465642bcb377030cad73386bcf6cf8cf565e3 and the all.yaml from this PR as well.