21–30 of 87 posts
Our hodgepodge of microservices- developed over more than a decade- never got coordinated env variables, so now we've got to go through like ~50 services & libraries, one by one, updating secrets. Yuck. If you do your shit right, you can just dump most of your secrets into some Contexts- containers of env variables- and apply them. Then when this stuff roles around, it's easy to update everything centrally; change th…
Our hodgepodge of microservices- developed over more than a decade- never got coordinated env variables, so now we've got to go through like ~50 services & libraries, one by one, updating secrets. Yuck. If you do your shit right, you can just dump most of your secrets into some Contexts- containers of env variables- and apply them. Then when this stuff roles around, it's easy to update everything centrally; change th…
No email? I found out about this from a random HN post?
[X] In case of a "security incident", lock down my account until I take action.
Better yet, also give me a button that does this even when there's no official incident reported. That means disabling all access tokens, resetting the password, halting any scheduled jobs, and revoking access for any connected OAuth services until I manually re-enable them.
No email? I found out about this from a random HN post?
I want the following option in my account settings for all critical services: [X] In case of a "security incident", lock down my account until I take action. I understand why they can't do that by default, but it's crazy that every time this happens, I have to run in order to secure my assets when in many cases, I'd be perfectly fine with things just shutting down until I have time to take care of them. Better yet, a…
Earlier quoted context omitted.
Can you elaborate, as someone with little AWS experience? Are OIDC based creds just more scoped? What makes them special?
To assume a role with OIDC you'd need to do it from the context of a specific CircleCI job run - getting access to the secrets of a particular CircleCI account alone would not be enough to authenticate to AWS (unlike when you use IAM user credentials). Even if the attacker had access to env vars from running jobs (which includes the signed token needed to do an OIDC role assumption), those tokens have a short expiry…
I want the following option in my account settings for all critical services: [X] In case of a "security incident", lock down my account until I take action. I understand why they can't do that by default, but it's crazy that every time this happens, I have to run in order to secure my assets when in many cases, I'd be perfectly fine with things just shutting down until I have time to take care of them. Better yet, a…
I don't think locking down the account will do anything. It sounds like secrets were already stolen. GitHub access tokens, etc. Locking the account won't unsteal that stuff.
Sounds like a separate product (something about breaches and blast radii) and not a CircleCI feature.
I want the following option in my account settings for all critical services: [X] In case of a "security incident", lock down my account until I take action. I understand why they can't do that by default, but it's crazy that every time this happens, I have to run in order to secure my assets when in many cases, I'd be perfectly fine with things just shutting down until I have time to take care of them. Better yet, a…
I don't think locking down the account will do anything. It sounds like secrets were already stolen. GitHub access tokens, etc. Locking the account won't unsteal that stuff.
Earlier quoted context omitted.
I don't think locking down the account will do anything. It sounds like secrets were already stolen. GitHub access tokens, etc. Locking the account won't unsteal that stuff.
Right. You'd need lock-down-all-AWS-controlled-by-the-foo-key because CircleCI got hacked and it had the foo-key. Sounds like a separate product (something about breaches and blast radii) and not a CircleCI feature.
CircleCI would like to:
- Upload build artifacts
- Report security incidents