Skip to content

GitLab Next

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
GitLab
GitLab
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 34,895
    • Issues 34,895
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 1,229
    • Merge Requests 1,229
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Security & Compliance
    • Security & Compliance
    • Dependency List
    • License Compliance
  • Operations
    • Operations
    • Metrics
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • GitLab.org
  • GitLabGitLab
  • Issues
  • #31113

Closed
Open
Opened Aug 21, 2019 by Bastian Blank@waldi

Create Kubernetes service account with role admin

Problem to solve

The service account created by the Kubernetes integration should be able to create further service accounts, roles and role bindings to deploy applications that need to communicate with Kubernetes.

Intended users

Unknown

Further details

Currently service accounts are created with the cluster role edit, which is automatically maintained and contains access all normal objects. It does however not include access to roles and role bindings.

This means that deploying and testing permission changes, even within this one namespace, can't be done via the Kubernetes integration. This can be fixed by applying the admin cluster role, which includes access to those objects.

Proposal

Change Clusters::Gcp::Kubernetes::PROJECT_CLUSTER_ROLE_NAME to admin.

Permissions and Security

Documentation

Update "Environment namespace" row in https://docs.gitlab.com/ee/user/project/clusters/add_remove_clusters.html#rbac-cluster-resources

Testing

What does success look like, and how can we measure that?

Links / references

Edited Oct 19, 2020 by Thong Kuah
Assignee
Assign to
13.6
Milestone
13.6 (Past due)
Assign milestone
Time tracking
None
Due date
None
Reference: gitlab-org/gitlab#31113