Establish policy for managing new users and projects

[larsks]

Right now we allow anyone to authenticate, and then grant self provisioning capabilities via group membership. Should we manage users and projects via git workflow?

[larsks]

Solution discussed on 2021-01-06 call:

• Manage projects (and project membership) via YAML files in repository
• Nobody gets self-provisioning privileges

[tumido]

Interesting alternative: Openshift native project templates. By setting "our" project template in openshift-config namespace we can modify the what RBAC is set on project creation.

A sample project template, which can be adjusted to our needs:

$ oc adm create-bootstrap-project-template -o yaml
apiVersion: template.openshift.io/v1
kind: Template
metadata:
  creationTimestamp: null
  name: project-request
objects:
- apiVersion: project.openshift.io/v1
  kind: Project
  metadata:
    annotations:
      openshift.io/description: ${PROJECT_DESCRIPTION}
      openshift.io/display-name: ${PROJECT_DISPLAYNAME}
      openshift.io/requester: ${PROJECT_REQUESTING_USER}
    creationTimestamp: null
    name: ${PROJECT_NAME}
  spec: {}
  status: {}
- apiVersion: rbac.authorization.k8s.io/v1
  kind: RoleBinding
  metadata:
    creationTimestamp: null
    name: admin
    namespace: ${PROJECT_NAME}
  roleRef:
    apiGroup: rbac.authorization.k8s.io
    kind: ClusterRole
    name: admin
  subjects:
  - apiGroup: rbac.authorization.k8s.io
    kind: User
    name: ${PROJECT_ADMIN_USER}
parameters:
- name: PROJECT_NAME
- name: PROJECT_DISPLAYNAME
- name: PROJECT_DESCRIPTION
- name: PROJECT_ADMIN_USER
- name: PROJECT_REQUESTING_USER

Reference: https://docs.openshift.com/container-platform/4.6/applications/projects/configuring-project-creation.html#modifying-template-for-new-projects_configuring-project-creation

This may be able to set all the permissions we need automatically on every project creation (when created by UI or oc new-project). I wonder if Argo CD can CreateProject instead of CreateNamespace somehow? cc @HumairAK

The other way around is what we outlined in the meeting, which is the fully declarative way - having each Namespace and all its RoleBinidings defined manually in our repo from where ArgoCD would pick them up and deploy on cluster and namespace scope.

[tumido]

It seems we can't make Argo CD to create the projects automatically (with RBAC inference etc.) So we should default to disabling the project creation from the UI/cli and only allow cluster admins to do that.

Next we can have a separate Argo CD application which would apply a set of manifests as a cluster admin, so we can track all the projects/namespaces/RBAC in a separate application within the Argo CD namespace. WDYT @HumairAK Would be https://github.com/operate-first/apps a suitable central location?

[HumairAK]

WDYT @HumairAK Would be https://github.com/operate-first/apps a suitable central location?

Oh that's a good question. These are cluster level resources, and if this is something cluster-admins are managing, it should probably stay in this repo.

[tumido]

FTR: We decided to run with an initial implementation to facilitate onboarding to https://github.com/open-infrastructure-labs/moc-cnv-sandbox/issues/8 and https://github.com/open-infrastructure-labs/moc-cnv-sandbox/issues/7, ADR will follow.

https://github.com/operate-first/apps/pull/104

[tumido]

Solution proposed as ADR: https://github.com/operate-first/blueprint/pull/19

[tumido]

Resolved via https://github.com/operate-first/blueprint/pull/19 and https://github.com/operate-first/apps/pull/120