19
JsonBoa
2y

Me: We need to allow the team in the newly acquired subsidiary to access our docker image repositories.
Sec Guy: Why?
Me: So they can run our very expensive AI models that we have prepared onto container images.
Sec Guy: There is a ban on sharing cloud resources with the acquired companies.
Me: So how we're supposed to share artifacts?!?
Sec Guy: Can't you just email them the docker files?
Me: Those images contain expensively trained AI models. You can't rebuild it from the docker files.
Sec Guy: Can't you email the images themselves?
Me: Those are a few gigabytes each. Won't fit in an email and won't even fit the Google drive / onedrive / Dropbox single file size limit.
Sec Guy: Can't you store them in a object storage like S3/GCS/Azure storage?
Me: Sure
Proceed to do that.
Can't give access to the storage for shit.
Call the sec guy
Me: I need to share this cloud storage directory.
Sec Guy (with aparent amnesia): Why?
Me: I just told you! So they can access our AI docker images!
Sec Guy: There is a ban on sharing cloud resources with the acquired companies.
Me: Goes insane

Is there a law or something that you must attempt several alternative methods before the sec people will realize that they are the problem?!?! I mean, frankly, one can get an executable artifact by fucking email and run it but can't pull it from a private docker registry? Why the fuck would their call it "security"?

Comments
  • 1
    We have an rule that no single system may access all servers, but there is an software that runs an agent that can nearly run anything on our servers(the only exception are rhel7+ servers because selinux prevents it)
  • 5
    That one is very easy to solve.

    Stop talk to the moronic Sec drone. Put everything in a short and sweet email:
    "Team A requires access to resources Alpha, Beta and Gamma. As per Relevant managers call. Please advise how to do that, As stated sec policy conflicts.

    Thanks."

    Send to sec guy. CC your manager, his manager, and every manager in thier chains, up to CTO/Whatever VP. Sit back, and watch the fireworks.
    Or.....
    go out, buy an external HD, and "docker save" the expensive top secret Company IP onto it. Then fedex it to the other team overnight. Make sure to CYA, by sending a vague email to sec guy.
  • 7
    @magicMirror we used DHL, but yeah, that is pretty much the only way to get large amounts of data through this level of stupid security limitations. Next time gonna use fucking torrents.
    The email tactics is a nice backside cover, though.
  • 3
    @JsonBoa
    heres an actual network solution. Its even secure! well - kinda.

    Step 1: machine at new team location, running a docker registry.
    Step 2: a machine at new team you can ssh to, and has remote ports enabled in the sshd config. probably behind a VPN. has docker installed, and sets hosts file with a line that uses the secret registry pointing to 127.0.0.1.
    Step 3: Machine at you site, that can VPN/ssh to Step 2, and has access to Super Top Secure Company Docker Registry.

    Then:
    Open vpn between 3 and 2.
    Open ssh connection from 3 to 2 with remote port set up. remote port should match the STSCDR port, and point to the STSCDR ip address on 3 side.
    Then you "docker pull" the images on Step 2. if you have problems - install the CA of STSCDR onto step 2. then retag the pulled images, and push to step 1.

    Why it works?
    You want to pull images from the registry. pulling requires access to the server. So you need to be able to dns resolve it to the ssh port.
  • 2
    @magicMirror
    $> sudo color me impressed
    that could work! I did manage to SSH to their systems a few days ago for an unrelated reason.
    Setting up the CA and settings is gonna be a bitch, but there is sure to be a docker registry that itself runs straight from a container (an Escher registry, if I might say)
    We're expecting new revisions on some AI models for Q3, I don't think that we will need DHL to deliver those... Thanks!
  • 3
    You are talking to the wrong person. Find the one who installed the no-share policy and get an exemption for exactly your use case with which you can go to the sec guy or cloud admin to have them make the resource accessible.
  • 3
    @JsonBoa
    😁.

    I once had to upload a file from my laptop to vm C@Location B.

    laptop can't ssh directly. no VPN to loc B.
    But can VPN to Location A and ssh to vm A@Location A.
    Vm A, cant ssh to vm C@Loc B directly, through site to site VPN. but... it can SSH to vm B@location B. VM B can then SSH to VM C.
    So.... scp from lappy>vm A>vm B>vm C? Big Fat Nope!

    Multi ssh local ports to the rescue!
    1. lappy opens VPN to A.
    2. "ssh vm A:22 L 5001:vm B:22"
    2. "ssh 127.0.0.1:5001 L 5002:VM C:22"
    3. "scp file 127.0.0.1:5002"
    Done! 😆
  • 3
    I was just thinking when reading along. WTF all listed alternatives are cloud solutions. Why is that allowed all the sudden. Well it isn't...

    I had the same bullshit with our security dumbasses. I'm very security minded so I wanted actually improve security and traceability. But nope bs policy that does not apply here is still enforced. Plus I had to defend against 🚩 comments in every conversation. And the crap they build for new account creation and activation had a catch-22 so nobody gets the activation token in the company however the new user can't get it either... Great security guys. What's next drop? drop our internet connection?

    So either you make it their problem. Doing some shit that overloads their systems for example or do what @magicMirror said if that is not possible.
  • 3
    @hjk101
    My previous company was very security "savvy".
    All clients installs were "on prem", non cloud, access via client specific VPNs.
    Internal company network was segragated using VLANs/firewall policies.

    My laptop could not access the internal docker registry directly, and had to pivot via My personal dev VM, I had to pull artifacts from one VLAN daily, and push to another. Ssh remote port ftw.

    Before my Ssh Remote port solution, Client deploys were done via double VPN - Open VPN to client system, And then VPN back to the internal docker registry, using a dedicated VPN user in order to pull the images.... Ssh remote port ftw.

    It got so bad, that I had setup the remote port by defualt on all my ssh sessions. Caused a fun problem - When trying to fix a problem with internal registry. Took me a few minutes to figure out what was using the registry port 🥴.
Add Comment