Skip to content

managing_projects.adoc

Latest commit

 

History

History
314 lines (251 loc) · 10.3 KB

managing_projects.adoc

File metadata and controls

314 lines (251 loc) · 10.3 KB
Raw

Managing Projects

Overview

In {product-title}, projects are used to group and isolate related objects. As an administrator, you can give developers access to certain projects, allow them to create their own, and give them administrative rights within individual projects.

Self-provisioning Projects

You can allow developers to create their own projects. There is an endpoint that will provision a project according to a template. The web console and oc new-project command use this endpoint when a developer creates a new project.

Modifying the Template for New Projects

The API server automatically provisions projects based on the template that is identified by the projectRequestTemplate parameter of the master-config.yaml file. If the parameter is not defined, the API server creates a default template that creates a project with the requested name, and assigns the requesting user to the "admin" role for that project.

To create your own custom project template:

  1. Start with the current default project template:

    $ oadm create-bootstrap-project-template -o yaml > template.yaml

  2. Use a text editor to modify the template.yaml file by adding objects or modifying existing objects.

  3. Load the template:

    $ oc create -f template.yaml -n default

  4. Modify the master-config.yaml file to reference the loaded template:

    ...
projectConfig:
  projectRequestTemplate: "default/project-request"
  ...

When a project request is submitted, the API substitutes the following parameters into the template:

Parameter Description

PROJECT_NAME

The name of the project. Required.

PROJECT_DISPLAYNAME

The display name of the project. May be empty.

PROJECT_DESCRIPTION

The description of the project. May be empty.

PROJECT_ADMIN_USER

The username of the administrating user.

PROJECT_REQUESTING_USER

The username of the requesting user.

Access to the API is granted to developers with the self-provisioner role and the self-provisioners cluster role binding. This role is available to all authenticated developers by default.

Disabling Self-provisioning

Removing the self-provisioners cluster role from authenticated user groups will deny permissions for self-provisioning any new projects.

$ oadm policy remove-cluster-role-from-group self-provisioner system:authenticated system:authenticated:oauth

When disabling self-provisioning, set the projectRequestMessage parameter in the master-config.yaml file to instruct developers on how to request a new project. This parameter is a string that will be presented to the developer in the web console and command line when they attempt to self-provision a project. For example:

Contact your system administrator at projectname@example.com to request a project.

or:

To request a new project, fill out the project request form located at
https://internal.example.com/openshift-project-request.

Limiting Number of Self-Provisioned Projects Per User

The number of self-provisioned projects requested by a given user can be limited with the ProjectRequestLimit admission control plug-in.

Important

If your project request template was created in {product-title} 3.1 or earlier using the process described in Modifying the Template for New Projects, then the generated template does not include the annotation openshift.io/requester: ${PROJECT_REQUESTING_USER}, which is used for the ProjectRequestLimitConfig. You must add the annotation.

In order to specify limits for users, a configuration must be specified for the plug-in within the master configuration file (/etc/origin/master/master-config.yaml). The plug-in configuration takes a list of user label selectors and the associated maximum project requests.

Selectors are evaluated in order. The first one matching the current user will be used to determine the maximum number of projects. If a selector is not specified, a limit applies to all users. If a maximum number of projects is not specified, then an unlimited number of projects are allowed for a specific selector.

The following configuration sets a global limit of 2 projects per user while allowing 10 projects for users with a label of level=advanced and unlimited projects for users with a label of level=admin.

admissionConfig:
  pluginConfig:
    ProjectRequestLimit:
      configuration:
        apiVersion: v1
        kind: ProjectRequestLimitConfig
        limits:
        - selector:
            level: admin (1)
        - selector:
            level: advanced (2)
          maxProjects: 10
        - maxProjects: 2 (3)

  1. For selector level=admin, no maxProjects is specified. This means that users with this label will not have a maximum of project requests.

  2. For selector level=advanced, a maximum number of 10 projects will be allowed.

  3. For the third entry, no selector is specified. This means that it will be applied to any user that doesn’t satisfy the previous two rules. Because rules are evaluated in order, this rule should be specified last.

Note

Managing User and Group Labels provides further guidance on how to add, remove, or show labels for users and groups.

Once your changes are made, restart {product-title} for the changes to take effect.