"Essentially, the jobs submission API performs, by default, no checks for authorization, allowing anyone who can reach the endpoint to add and remove work, access information, and perform other things they really shouldn't be able to.”
https://www.theregister.com/2024/03/27/ray_ai_framework_bug/
Mastodon Source 🐘
IYKYK 27017
https://docs.bitnami.com/google-templates/security/security-2017-01-04/
Mastodon Source 🐘
That security is delegated to a trusted isolated network (“Security and isolation must be enforced outside of the Ray Cluster” - https://docs.ray.io/en/latest/ray-security/index.html#best-practices) is understandable. Although, the network is never secure and it takes a mature engineering org to provide this capability to _every_ developer working on a feature as part of their CI/SDLC.
I can also imagine how this puts SecOps/NetEng in an adversarial role: “It already works, we saw the demo. Why can’t you deploy it?”
Mastodon Source 🐘
Building from development to production is less effective than extracting production constraints and pulling those back into development.
The second one is initially longer lead time with shorter subsequent cycle times. The first one feels good until it doesn’t.