WARNING: Jenkins X version 2.x is unmaintained. Do not use it.
Please refer to the v3 documentation for the latest supported version.
Jenkins X uses Role-Based Access Control (RBAC) policies to control access to its various resources. The enforcement of the policies is provided by Kubernetes’ RBAC support.
Teams can have a number of Environments (e.g., Dev, Staging, Production) along with dynamic Preview Environments; keeping the
RoleBinding resources from Kubernetes RBAC in sync with all the various namespaces and members of your team can be challenging.
To make this management easier, Jenkins X creates a new Custom Resource called
EnvironmentRoleBinding which allows you to associate a
Role labeled with
jenkins.io/kind=EnvironmentRole with as many
ServiceAccounts as you like. As Environments are created or the
EnvironmentRoleBinding in the Dev environment is modified, the
role controller ensures that the configuration is replicated to all the environment namespaces by creating or updating all of the
RoleBindings per namespace.
Roles are per Team so it is possible to have special roles per team, or to use common names for roles but have them customized for each team.
Security Implications for the admin namespace
Jenkins X stores various configuration and settings (e.g.,
Teams) in the main admin namespace (
jx). Be careful when granting roles in the default
jx team as allowing users to edit some of these files may allow them to escalate their permissions.
Instead of granting non-admin users access to the
jx namespace, create teams and grant users access to those when using a shared cluster.
Jenkins X ships with a collection of default
Role objects you can use in the
jenkins-x-platform template. You can create your own if you wish, but any edits may be lost when Jenkins X is upgraded.
viewerrole allows access to read projects, builds, and logs. It does not allow access to sensitive information
committerrole provides the same permissions as
viewerand allows the user to trigger builds and import new projects.
- The owner role allows users to modify all team resources.
To add users use the jx create user command:
jx create user --email "email@example.com" --login joe --name "Joe Bloggs"
Changing User Roles
To modify the roles for a user, use jx edit userroles:
jx edit userrole --login joe
If you omit the
-l) flag, you will be prompted to pick the user to edit.
For example, to make a user
joe have the
committer Role (and remove any existing roles):
jx edit userrole --login joe --role committer
If you have fine-grained roles and want to grant multiple roles to a user, you can specify the roles as a comma-separated list:
jx edit userrole --login joe --role committer,viewer
Modifying a user’s roles changes the
EnvironmentRoleBinding. The role controller will replicate these changes to all the underlying Environment namespaces.
Was this page helpful?
Glad to hear it! Please tell us how we can improve.
Sorry to hear that. Please tell us how we can improve.