Feature Requests

To use the entire context security functionality, your repository must be on Github (because BitBucket doesn't have a groups API). I would like CircleCI to offer a UI to manage user group access so VCS providers that don't have group support can still take advantage of context security.Otherwise all of our developers end up having access to production API keys. CCI-I-1596

It would be nice to have additional metadata, such as branches or workflow names in the context token. Our application for this is we have separate workflows for different packages in a monorepo, and we would like to be able to gate access to different sets of cloud permissions based on the branch or workflow that is being executed.

In the UI, I'd love to be able to sort contexts by name or creation date.

We would like to use contexts to select the secrets that each job of a workflow can have access to, but those context should not be shareable accros project. Environment variables can be set on project basis, but they are shared accros all the jobs. By creating project specific contexts, we could have a more fine-grained control over the secrets shared between the jobs, without sharing them with other projects.

It would be useful to be able to specify multiple Context's in a workflow. As a general best security practice, any given workflow should only have access to the secrets that it absolutely needs. In order to accomplish this with Context's currently however, many projects would need their own Context, containing only the secrets relevant to that project. This defeats the point of Contexts, making them less reusable. Allowing a workflow to specify multiple Contexts maintains this principle of least privilege, without sacrificing the usability of Contexts. Exampe: workflows: main: jobs: - example-job: context: - AWS - Heroku - Cloudflare There's more discussion in this forum thread. CCI-I-761

There are whole categories of env vars that should be shared across an organization. (Like API keys or credentials for package hosting services like gemfury.) The Contexts feature is nice but unhelpful for jobs that aren't using workflows. Related... why does the Import Env Var feature require admin privileges? If I have access to _add_ an env var, and I have access to the env vars of other projects, then by definition I should have access to import an env var from another project (to which I have env var access) into another project (to which I also have env var access). CCI-I-467

Customers have various reasons to want to inject whole files as part of a Context, especially when doing things like inserting SSH keys or K8s config, etc. that are shared across projects and/or managed by central admin. The concept is that we'd add a set of files to a context. Each would allow upload of a file and/or a textarea where one could paste the contents of a file, and each one would also take a path. At run time, when using a Context, the file would be inserted at the path specified. We'd likely want to have a way to inject it at an absolute path or relative to the working directory, as there are scenarios for each. Alternatively, it might make sense to allow overriding the path of injection in config, but that could get messy. CCI-I-28