allow private namespaces for orbs w/ CircleCI

Many organizations using orbs would most likely want to publish their orbs privately.

I assume orbs will be scoped to your GitHub org as namespace?

So it would be great if we can publish orbs to foobar/wizzle (assuming GH org foobar), and to have those be only visible to users / jobs within org "foobar"

  • Guest
  • Sep 17 2018
  • Taking votes
  • Attach files
  • Guest commented
    December 18, 2018 18:17

    Does "planned" mean this is already on the product roadmap? If so, can anyone clarify on when you plan to include this feature?

  • Bryan Campbell commented
    January 06, 2019 14:48

    We're really loving the great reuse we get out of Orbs, we just wish we could use them to share our internal tooling within our organization.

    https://discuss.circleci.com/t/organization-private-orbs/26085

  • Chris LeBlanc commented
    January 10, 2019 13:27

    Did this just take a step backwards by moving to "Future consideration?" from "Planned"?

  • Admin
    Nathan Dintenfass commented
    January 10, 2019 19:46

    We're working to clean up "Planned" to mean work that's already in progress rather than meaning "things we hope to do" to avoid setting bad expectations about timing. This is still something very much on our radar, but we're not actively building it yet.

  • Dean Galvin commented
    January 10, 2019 20:02

    @nathan is there any tentative date that Circle is targeting for this?

  • Admin
    Nathan Dintenfass commented
    January 11, 2019 07:04

    I have no guidance to give for dates on this (in general, we don't like to set any expectations about dates until things are already under active development) 

  • Gabriel Volpe commented
    January 28, 2019 06:27

    Would love to have this feature! I work in the fintech industry and we are under heavy regulation so this would help us very much in stop repeating our builds.

  • Richard Clayton commented
    January 30, 2019 15:29

    Given Orbs are basically the only way to reduce YAML boilerplate across projects, I honestly would think Private orbs would have been the default (or first implementation).

  • Dean Galvin commented
    January 30, 2019 16:52

    Is this still only a future consideration? Is it not planned at all to work on?

  • Alexandre Andrade commented
    February 04, 2019 23:11

    Many people requesting it..

  • Ivan Ilves commented
    February 12, 2019 12:01

    Many people requesting it... but where are any movements from Circle? :-\ 

  • Admin
    Nathan Dintenfass commented
    February 12, 2019 20:12

    We are very aware of the desire here. At the moment this work sits behind some changes to our underlying security model that are part of some larger efforts that are underway. 

  • Oron Riff commented
    February 25, 2019 16:52

    +1

  • Filip Tepper commented
    April 08, 2019 11:13

    Any updates on this? Or perhaps there's a place where we could monitor progress or ETAs?

  • Nguyen Duc Toan commented
    April 09, 2019 09:52

    Really looking forward to this feature.

  • Marcelo Pires commented
    April 09, 2019 11:34

    I 'd really liked to see this feature, would be very helpful

  • Jason Hoos commented
    April 26, 2019 15:10

    A short-term suggestion (which I also mentioned on CCI-I-704) until we can get true private repos: can we have an augmented syntax for referencing orbs that would allow them to be pulled from a URL or Docker image?

  • Mattias Ek commented
    May 29, 2019 20:06

    Any progress? This issue is a real show stopper for us

  • Emerson Farrugia commented
    May 30, 2019 16:59

    I was super excited to get rid of all repetition across many apps and microservices, and then saw that it's public only. Orbs are a brilliant feature that a lot of people are never going to use. They're utterly hamstrung by being public only.

  • Guest commented
    June 14, 2019 13:36

    Are we able to get an update on this? It has been in "Taking Votes" for a while & seems to have a decent number of votes. 

  • قناة شليلة commented
    June 24, 2019 13:14

    قناةشليلةhttps://cl.ly/a92646

  • Adrian Norte commented
    July 15, 2019 13:57

    Any news in this?

  • Lydia Tripp commented
    July 31, 2019 21:48

    This feature would be very helpful to my team.  We would like to be able to share configuration between git-repos internally.

  • Sebastian Garn commented
    August 09, 2019 10:28

    +1

  • Admin
    Nathan Dintenfass commented
    August 20, 2019 17:39

    Curious to know: for those who want this feature, would it be sufficient if your orb were "hidden" from being listed on the public registry UI, or do you actually need it to be inaccessible by others? We generally recommend (strongly) against putting secrets into configuration, which would extend to orbs, so we may offer the ability to "hide" your orb (but still be accessible when referenced directly), which is much smaller in scope. But before we do that I figured I'd solicit some input from folks who voted or this to get a feel or how many of you would be satisfied with that.

  • Richard Clayton commented
    August 20, 2019 17:42

    @Nathan  Hidden would be enough for me.

  • Adrian Norte commented
    August 20, 2019 17:44

    @Nathan

     

    Hidden can be a good start but even if we do not put secrets in there, the build is a reflection on how the servers artifacts are made and even if you try to reduce the amount of sensible info in there it can help an attacker to figure out how your servers and programs work together.

  • Christopher Rung commented
    August 20, 2019 17:45

    @Nathan, it would definitely be sufficient for us to have orbs be "hidden."

    I'm excited by the prospects of orbs for DRY purposes. Since our build process is unique, I don't think it would be of much use to other orgs, which is why we were hesitant to publish it publicly.

    Thank you!

  • Phil Schuler commented
    August 20, 2019 17:51

    @Nathan "hidden" Orbs would certainly be a good start and is likely solving the problem for some folks. Ultimately, completly private Orbs are certainly desirable for those who have to meet compliances or cannot risk exposing their private orbs for other reasons

  • Robby Marston commented
    August 20, 2019 17:52

    @Nathan +1 to hidden, it's a nice forcing function to address the abstraction of 'secret' contents from our configurations. Thank you for addressing this idea!

  • Phil Nielsen commented
    August 20, 2019 17:55

    Piling on with another vote, hidden is totally fine for our use case as well!

  • Jeff Fairley commented
    August 20, 2019 17:56

    @Nathan, "hidden" orbs would cover me. I agree that secrets should be elsewhere.

     

    If the general public were using my orbs, my biggest concern would be things that tend to go along with maintaining public software, like making orbs backwards compatible or properly versioned. Basically, I want to create orbs that are specific to my workflows and feel free to completely change them at any time with no fear of blow-back.

  • Toby Pinder commented
    August 20, 2019 18:00

    @Nathan

     

    Hidden would be pretty insufficient I believe as attackers could enumerate orbs pretty easily. To be clear we still use circleci orbs, but a private orb model would greatly improve things.

     

    We understand and share your guidance on not storing sensitive information in Orbs but the complexity comes from managing risk as an organisation - if secrets leak into our github repos they are private and there is time to detect and rotate them, for example, but if something were to accidentally enter an Orb then we would have no recourse or control.

     

    As well as this, leaking information on how builds are processed via our Orb is providing an attacker with open source intelligence - they now have information on potential upstream software to look at exploiting or attacking directly. Security by obscurity is not an adequate control but at the same time many orgs would be hesitant to effectively document their build pipeline and release it publicly.

     

    Finally, I can imagine there are some for whom the licensing requirements for public orbs prevent them from being capable of using Orbs to their full advantage. Tools/Scripts/etc can be obfuscated by putting them inside eg commands, containers etc but this just adds to complexity, and it's hard to put audit controls around vs just having "use private repo only" as the organisational setting.

  • Sergio Morales commented
    August 20, 2019 18:21

    +1

  • Mattias Ek commented
    August 20, 2019 18:31

    @Nathan, unfortunatly

  • Mattias Ek commented
    August 20, 2019 18:36

    @Nathan, due to legal reason not, we need privacy for the orbs.  This is a blocker for our orb usage.

  • Dan Green-Leipciger commented
    August 20, 2019 18:48

    I think hidden orbs would suffice for much of our use. We would like to have orbs that would be useless to people other than us but do not contain anything sensitive

  • Dave Mason commented
    August 20, 2019 19:14

    For me it needs to be truly private. We don't keep any secrets inside our Circle config, but you could infer a lot about our architecture if you were to view it. I'd prefer to keep that information completely private.

  • guest commented
    August 20, 2019 21:02

    @Nathan needs to be actually private although "secret" like GitHub Gists (non-predictable path) might , maybe, possibly satisfy the corporate requirements that constrain us from using orbs currently.

  • Gavin Harcourt commented
    August 22, 2019 11:14

    To re-iterate some points already made it would be open sourcing intelligence into our build practices, tooling and tech stack. Most of the orbs we want to create are for making our own custom pipelines DRY rather than to provide common functionality that could be reused by other companies. We also wouldn't want to take on the responsibility of maintaining a public orb.

  • Eric Bode commented
    August 27, 2019 13:22

    As long as the hidden orbs get a UUID to be able to reference them directly I think it would suffice. For me it is the same as previous people have mentioned, the workflows are specific to us and we do not need to be able to maintain public backwards compatible orbs not to mention the images we use are on a private registry so it would not benefit the public anyway.

  • Filip Tepper commented
    September 02, 2019 05:35

    I definitely need it to be truly private. I would go as far as saying that some parts of the build process are a trade secret from security perspective.

  • Dominik commented
    September 04, 2019 09:14

    @Nathan:

    We want to be able to phase-out older orb versions in our company-internal workflows. We have checks running in the orbs which are company specific & will change over time.
    These orbs should not be publicly available as we don't guarantee any long-term maintenance on any version.


    For our use-case, we would:

    * either just need hidden orbs (as we don't put any secrets in orbs) and whitelisting our orb namespace (https://ideas.circleci.com/ideas/CCI-I-687)
    * or a third-party orb registry (https://ideas.circleci.com/ideas/CCI-I-819)

  • Admin
    Sara Read commented
    September 17, 2019 23:41

    Hi Everyone! It is now possible to unlist orbs from the registry search results by using our CLI. Documentation to do so can be found at: https://circleci-public.github.io/circleci-cli/circleci_orb_unlist.html.

     

    Please note that:

    • Unlisted orbs can be listed in the orb registry again with the same CLI command.
    • Only org admins can unlist/list orbs.
    • Unlisting an orb does not affect its ability to be referenced by name in builds or for its source to be viewed.
  • Manuele Cavalli-Sforza commented
    September 17, 2019 23:50

    Thanks for the update! Are there any plans to develop fully private orbs? This is a blocker for our use case as well.

  • Guest commented
    September 18, 2019 06:40

    +1 for real private orbs. unlisting is not enough..

  • Guest commented
    September 20, 2019 18:48

    Really need this feature. There really aren't many options for sharing config across projects in CircleCi, there's pretty much no way to DRY out config at the moment. And having the orbs unlisted makes no difference, if the source can be seen then it represents a security concern and most companies are not going to be willing to allow that.

  • Giuseppe Landolfi commented
    September 23, 2019 07:28

    +1 from here as well. We're migrating to CircleCI and this one is the single most important thing that we miss. We're duplicating A LOT of config across projects because having our build steps public is not an option.

  • Igor Belikov commented
    October 16, 2019 07:53

    Any progress on this? This is the most upvoted idea, having some kind of solution for this (and unlisting is not a real solution for a lot of us here) would be greatly appreciated.

    I had to create ~70 pull requests recently just because using orbs is a no go until there are private namespaces. If there's no real timeline on having them, I'd rather spend my time on migrating away from CircleCI at all.

  • Timothy c commented
    December 03, 2019 16:22

    Hidden is enough for our usecase

  • Aviad Shikloshi commented
    December 09, 2019 08:58

    +1

  • Bryan Campbell commented
    December 19, 2019 20:06

    Today we opened 160 PRs to update our build configs from node 10 to node 12. Sure would be nice to be able to centralize our configuration into a private orb.

  • Joao Henrique Machado Silva commented
    19 Jan 22:24

    It's really a shame that this feature does not exists yet. It seems like a trivial thing to have in my opinion. And very important based on the amount of comments. 

  • ANDREW HILTON commented
    24 Jan 14:13

    +1