New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFC: RBAC #6

Open
wants to merge 10 commits into
base: master
from

Conversation

Projects
None yet
8 participants
@pivotal-jwinters

pivotal-jwinters commented Jul 18, 2018

Proposal

Status: Draft

This doesn't seem like that big of a change, and I think most proposed changes are fairly straight forward. I'm not a huge fan of my proposed solution for fly set-team, but with our static flags (i.e. --github-user) being as they are, I can't really see how else this would work.

Or you can view the original issue

pivotal-jwinters added some commits Jul 18, 2018

@xtreme-sameer-vohra

This comment has been minimized.

xtreme-sameer-vohra commented Jul 18, 2018

Copying from #2389

As an alternative to require 2 commands to set some viewers & members, could we also consider alternatives that might allow configuring a team with a single command.
This would remove the point mentioned above

The main drawback here is that we would have to merge auth configuration because viewers and members would be configured in two separate steps. The current behaviour overwrites the entire auth config each time, so in keeping with the current behaviour I guess we would overwrite the entire config for each role separately.

For example set-team could allow you to specify a config file with the following content

{
	"viewer": {
		"groups": [],
		"users": []
	},
	"member": {
		"groups": ["github:myorg:myteam"],
		"users": ["github:pivotal-jwinters"]
	}
}
@xtreme-sameer-vohra

This comment has been minimized.

xtreme-sameer-vohra commented Jul 18, 2018

For the team viewer role, should they be able to access the team resource itself including the auth config ?
That might be an operation that we might restrict to team members only.

@vito

Makes a lot of sense to me! Left some suggestions inline.

fly -t mytarget set-team -n myteam --role member --github-user pivotal-jwinters --github-team myorg:myteam
```
The main drawback here is that we would have to merge `auth` configuration because `viewers` and `members` would be configured in two separate steps. The current behaviour overwrites the entire auth config each time, so in keeping with the current behaviour I guess we would overwrite the entire config for each role separately.

This comment has been minimized.

@vito

vito Jul 18, 2018

Member

I think this makes sense, but at this point maybe we should explore having team config files instead, and having it set everything at once, including all the roles. Kind of like Vault's policy config files: https://www.vaultproject.io/docs/concepts/policies.html (in spirit)

We could then allow configuring multiple teams on ATC start by pointing it at the config files. This would even make the main team no longer "special" - it'd just be among the set of teams configured at start, with admin set to true.

This comment has been minimized.

@pivotal-jwinters

pivotal-jwinters Jul 18, 2018

But the million dollar question is: YAML, JSON, TOML, HCL, ...?

I'm assuming we're going to stick to YAML since users are used to writing pipeline YAMLs?

This comment has been minimized.

@vito

vito Jul 18, 2018

Member

Yeah, probably YAML.

This comment has been minimized.

@pivotal-jwinters

pivotal-jwinters Jul 18, 2018

@xtreme-sameer-vohra I'm wondering if your exported team list should match the config format that we choose?

This comment has been minimized.

@xtreme-sameer-vohra

xtreme-sameer-vohra Jul 19, 2018

@pivotal-jwinters Yep, it makes sense for fly teams to be able to export team contents in the same format such that it could be used for set-teams as well/

`team_viewer` or `viewer` - Granted during `fly set-team`. Has readonly access to all the team's resources.
`public` - Not a role. This applies to pipelines. Public pipelines will behave as they did before.

This comment has been minimized.

@vito

vito Jul 18, 2018

Member

Kinda confusing to list this under roles. :P Maybe we need a new name for this? It applies to jobs, too, so I could see a pattern forming here.

@xtreme-sameer-vohra

This comment has been minimized.

xtreme-sameer-vohra commented Jul 20, 2018

Would we consider seeded teams ( created via the manifest ) static ?
If we allow users to also update a particular team that was configured in the manifest by using fly set-team or fly set-teams then it will be hard to infer the desired behaviour.

@vito

This comment has been minimized.

Member

vito commented Jul 20, 2018

@jama-pivotal

This comment has been minimized.

Member

jama-pivotal commented Jul 27, 2018

This is the permission matrix I've written up to capture both fly and web view actions for each potential member. It's not comprehensive but should cover most use cases.

https://docs.google.com/spreadsheets/d/1np3hyJy3mVRfB2gcgKykz3QTQg5qEj28QgK523SEmao/edit#gid=0

@jchesterpivotal

This comment has been minimized.

jchesterpivotal commented Jul 31, 2018

Dumb question: will this overlap with or cause confusion vs Kubernetes RBAC?

```yaml
teams:
main:
admin: true

This comment has been minimized.

@ebabani

ebabani Jul 31, 2018

Should this be configurable for the main team? What's the recovery if someone makes this false?

# Proposal
## What roles do we need?

This comment has been minimized.

@william-tran

william-tran Jul 31, 2018

Here are our needs, at a minimum:

  • dashboard - we have a custom dashboard. It needs GET access to the following and no more, so that the credentials that the dashboard uses can't be used to get build logs that could leak other credentials.
    • /api/v1/teams/{team}/pipelines
    • /api/v1/teams/{team}/pipelines/{pipeline}/jobs
    • /api/v1/teams/{team}/pipelines/{pipeline}/resources (to display check failures)
    • /api/v1/teams/{team}/pipelines
    • /api/v1/teams/{team}/builds
  • user - everything in their team, except set-team, hijack, execute, set-pipeline. We want to ensure every action that concourse does is auditable. We have a pipeline that gets pipeline configs from git, and does the set-pipeline-ing, and we need to ensure that is the only way that pipelines can be set
  • admin - everything

Because these roles and permissions are quite a bit different, and I'm sure others will have their own idea of what they should be, it would be great if this was configurable.

@Rukenshia

This comment has been minimized.

Rukenshia commented Sep 19, 2018

Hi, just read through the RFC and have a couple of questions hoping it is the correct place to ask them:

Is this RFC for "default" roles with predefined permissions? I think this feature should be very configurable for admins as there are probably lots of organisations out there with different compliance requirements that won't be covered by the roles mentioned in the RFC. We have quite a few roles involved in our release process (ugh...) so it would be awesome if I could create my own role, attach permissions to it and then assign that to users.

I am thinking basically having a permission for each kind of action in concourse (i.e. all CLI commands) that can be assigned to roles.

If that is the case, I definitely would add a role that can view pipelines and manually trigger jobs in them, but not update the pipeline configuration. We need this for our "Release Approvers" that are basically just the people pushing buttons to mark their approval for the release.

If this is not the correct place, please tell me where I should add it. Thanks 😊

@william-tran

This comment has been minimized.

william-tran commented Sep 19, 2018

Here here, I'm hoping we get the ability to define our own roles, this would save us a lot of work in writing our own proxy with auth etc.

@pivotal-jwinters

This comment has been minimized.

pivotal-jwinters commented Sep 19, 2018

@Rukenshia @william-tran our first pass at RBAC is going to have static roles, but we have started thinking about what dynamic roles might look like.

The thought (similar to what @Rukenshia mentioned) is that down the road you'll be able to map specific actions to whatever you want, but our initial action/role mapping will probably look something like the following:

	atc.DestroyTeam:                   "admin",
	atc.RenameTeam:                    "admin",
	atc.SetTeam:                       "admin",
	atc.AbortBuild:                    "member",
	atc.CheckResource:                 "member",
	atc.CheckResourceType:             "member",
	atc.CheckResourceWebHook:          "member",
	atc.ClearTaskCache:                "member",
	atc.CreateBuild:                   "member",
	atc.CreateJobBuild:                "member",
	atc.CreatePipelineBuild:           "member",
	atc.DeletePipeline:                "member",
	atc.DeleteWorker:                  "member",
	atc.DisableResourceVersion:        "member",
	atc.EnableResourceVersion:         "member",
	atc.ExposePipeline:                "member",
	atc.HeartbeatWorker:               "member",
	atc.HidePipeline:                  "member",
	atc.HijackContainer:               "member",
	atc.LandWorker:                    "member",
	atc.OrderPipelines:                "member",
	atc.PauseJob:                      "member",
	atc.PausePipeline:                 "member",
	atc.PauseResource:                 "member",
	atc.PruneWorker:                   "member",
	atc.ReadOutputFromBuildPlan:       "member",
	atc.RegisterWorker:                "member",
	atc.RenamePipeline:                "member",
	atc.ReportWorkerContainers:        "member",
	atc.ReportWorkerVolumes:           "member",
	atc.RetireWorker:                  "member",
	atc.SaveConfig:                    "member",
	atc.SendInputToBuildPlan:          "member",
	atc.SetLogLevel:                   "member",
	atc.UnpauseJob:                    "member",
	atc.UnpausePipeline:               "member",
	atc.UnpauseResource:               "member",
	atc.BuildEvents:                   "viewer",
	atc.BuildResources:                "viewer",
	atc.DownloadCLI:                   "viewer",
	atc.GetBuild:                      "viewer",
	atc.GetBuildPlan:                  "viewer",
	atc.GetBuildPreparation:           "viewer",
	atc.GetConfig:                     "viewer",
	atc.GetContainer:                  "viewer",
	atc.GetInfo:                       "viewer",
	atc.GetInfoCreds:                  "viewer",
	atc.GetJob:                        "viewer",
	atc.GetJobBuild:                   "viewer",
	atc.GetLogLevel:                   "viewer",
	atc.GetPipeline:                   "viewer",
	atc.GetResource:                   "viewer",
	atc.GetResourceCausality:          "viewer",
	atc.GetResourceVersion:            "viewer",
	atc.GetVersionsDB:                 "viewer",
	atc.JobBadge:                      "viewer",
	atc.ListAllJobs:                   "viewer",
	atc.ListAllPipelines:              "viewer",
	atc.ListAllResources:              "viewer",
	atc.ListBuilds:                    "viewer",
	atc.ListBuildsWithVersionAsInput:  "viewer",
	atc.ListBuildsWithVersionAsOutput: "viewer",
	atc.ListContainers:                "viewer",
	atc.ListDestroyingContainers:      "viewer",
	atc.ListDestroyingVolumes:         "viewer",
	atc.ListJobBuilds:                 "viewer",
	atc.ListJobInputs:                 "viewer",
	atc.ListJobs:                      "viewer",
	atc.ListPipelineBuilds:            "viewer",
	atc.ListPipelines:                 "viewer",
	atc.ListResourceTypes:             "viewer",
	atc.ListResourceVersions:          "viewer",
	atc.ListResources:                 "viewer",
	atc.ListTeamBuilds:                "viewer",
	atc.ListTeams:                     "viewer",
	atc.ListVolumes:                   "viewer",
	atc.ListWorkers:                   "viewer",
	atc.MainJobBadge:                  "viewer",
	atc.PipelineBadge:                 "viewer",

pivotal-jwinters added some commits Oct 5, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment