CircleCI Ideas

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"

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Sep 17 2018
  • Taking votes
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    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?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    06 Jan 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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    10 Jan 13:27

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

  • Admin
    Nathan Dintenfass commented
    10 Jan 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    10 Jan 20:02

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

  • Admin
    Nathan Dintenfass commented
    11 Jan 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) 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    28 Jan 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    30 Jan 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).

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    30 Jan 16:52

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    04 Feb 23:11

    Many people requesting it..

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    12 Feb 12:01

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

  • Admin
    Nathan Dintenfass commented
    12 Feb 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. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    25 Feb 16:52

    +1

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    08 Apr 11:13

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    09 Apr 09:52

    Really looking forward to this feature.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    09 Apr 11:34

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    26 Apr 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?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    29 May 20:06

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    30 May 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    14 Jun 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. 

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    24 Jun 13:14

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    15 Jul 13:57

    Any news in this?

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    31 Jul 21:48

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    09 Aug 10:28

    +1

  • Admin
    Nathan Dintenfass commented
    20 Aug 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 17:42

    @Nathan  Hidden would be enough for me.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 17:55

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 18:21

    +1

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 18:31

    @Nathan, unfortunatly

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 18:36

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Aug 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    22 Aug 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    27 Aug 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    02 Sep 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    04 Sep 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)

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    17 Sep 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.
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    17 Sep 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.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    18 Sep 06:40

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

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    20 Sep 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.