|
Google isn't particularly well known for being very hands on and personal with their support. On the other hand, scaling support like how AWS works really sucks and is really expensive so it'll likely go to enterprise accounts primarily in practice I'd wager.
|
#
?
Aug 23, 2016 16:29
|
|
|
|
| # ? May 5, 2024 18:39 |
|
|
Potato Salad posted:What else are they gonna do? necrobobsledder posted:Google isn't particularly well known for being very hands on and personal with their support. On the other hand, scaling support like how AWS works really sucks and is really expensive so it'll likely go to enterprise accounts primarily in practice I'd wager.
|
|
#
?
Aug 23, 2016 17:10
|
|
|
DevNull posted:Someone's script being able to just disable VMs doesn't seem like a good place to be. http://www.fredtrotter.com/2016/08/22/google-intrusion-detection-problems/ That seems pretty bad, although you should have a proper support contract if you are running "multiple critical data stores" on cloud storage jre fucked around with this message at 22:58 on Aug 23, 2016 |
|
#
?
Aug 23, 2016 22:51
|
|
|
Current pissy Azure rant:
|
|
#
?
Aug 27, 2016 18:49
|
|
|
I literally lodged a ticket 6 hours ago and they responded via e-mail which I selected so I dunno what's up.
|
|
#
?
Aug 27, 2016 19:01
|
|
|
cheese-cube posted:I literally lodged a ticket 6 hours ago and they responded via e-mail which I selected so I dunno what's up. e: I also picked the Azure feature request thing to complain because I told support directly and they told me to post it there "so their product team could capture it" because this is nobody's problem Vulture Culture fucked around with this message at 20:08 on Aug 27, 2016 |
|
#
?
Aug 27, 2016 19:12
|
|
|
I am having the hardest time to get my LDAP to work with OpenStack. Anyone willing to offer some help guiding me through? Thanks.
|
|
#
?
Aug 30, 2016 22:02
|
|
|
Relevant portions of keystone.conf? Brief description of ldap structure (what OUs are the users in, etc)?
|
|
#
?
Aug 30, 2016 22:54
|
|
|
Has anyone had to solve for MFA on an AWS root account? Our compliance people are enforcing that we enable MFA on all of our Amazon accounts that my team manages, which isn't unreasonable. However, our team is 6 people, and we're trying to figure out how we can have a virtual MFA device that we all have access to. Email doesn't appear to be an MFA option, which would make this trivial via distribution list. I feel like someone would have figured this out already, but I'm sort of stumped at the moment. Aside from registering a google voice number for SMS that relays to a team member, I'm not sure what else we can try. Edit: To clarify, this is for emergency access. We have federated authentication that we use for day to day administrivia. Use of the root account would only be if something was badly broken. But we still want to make it so whomever is on-call has a way to get in without having to harass somebody else for their google authenticator. Cidrick fucked around with this message at 20:08 on Sep 15, 2016 |
|
#
?
Sep 15, 2016 20:03
|
|
|
Hardware token and a webcam 
|
|
#
?
Sep 15, 2016 20:11
|
|
|
Can you not hand the same oauth keys out to multiple google authenticators? Also: Cidrick posted:> To clarify, this is for emergency access Kinda sounds like convenience is out of scope here. If federated services go down, you're in a situation where it is more than appropriate to call up a team member. Additionally, depending on the compliance set you're being forced to work with, it may be inappropriate for you guys to each individually have access to root accounts wherein the technician who logged into it cannot be audited. It is appropriate in some circumstances to require a key / password release procedure that logs who requested access and why. The only thing that ought to be able to defeat your audit trail is collusion. Potato Salad fucked around with this message at 20:29 on Sep 15, 2016 |
|
#
?
Sep 15, 2016 20:26
|
|
|
Cidrick posted:Has anyone had to solve for MFA on an AWS root account? Our compliance people are enforcing that we enable MFA on all of our Amazon accounts that my team manages, which isn't unreasonable. However, our team is 6 people, and we're trying to figure out how we can have a virtual MFA device that we all have access to. Email doesn't appear to be an MFA option, which would make this trivial via distribution list.
|
|
#
?
Sep 15, 2016 20:27
|
|
|
Backup codes / hardware token that's kept in a safety deposit box? Those require that you're in an access list, check drivers licenses, and log who uses it when.
|
|
#
?
Sep 15, 2016 20:37
|
|
|
Vulture Culture posted:Send them all a picture of the QR code Based on some rudimentary Googling, it seems like the QR code is only valid once, unless you time it that multiple devices use that QR code at the exact same time. I haven't tested this, obviously. Potato Salad posted:Kinda sounds like convenience is out of scope here. If federated services go down, you're in a situation where it is more than appropriate to call up a team member. Additionally, depending on the compliance set you're being forced to work with, it may be inappropriate for you guys to each individually have access to root accounts wherein the technician who logged into it cannot be audited. It is appropriate in some circumstances to require a key / password release procedure that logs who requested access and why. The only thing that ought to be able to defeat your audit trail is collusion. It's not merely a convenience thing. If you have One Phone and that phone's battery is dead, or accidentally gets wiped, or the person who owns it is in a cave and can't respond to a phone call, you're still out of luck. We may end up using something like oathtool as a virtual MFA device. Of course, that opens up the question of 'where do we host it that we all have access to that doesn't use the same credentials as our federated access'. Which isn't really much of a problem now that I think about it, I guess, but I cringe at the second factor simply being password-protected host somewhere.
|
|
#
?
Sep 15, 2016 20:44
|
|
|
Cidrick posted:Based on some rudimentary Googling, it seems like the QR code is only valid once, unless you time it that multiple devices use that QR code at the exact same time. The QR code just represents the shared secret. You probably should only look at it once, but you can enroll as many devices as you want at that time. As long as their clocks are synchronized they will generate the same codes. When I set up 2FA I always enroll both my phone and my tablet using the same QR code, in case one of them dies.
|
|
#
?
Sep 15, 2016 21:32
|
|
|
Novo posted:The QR code just represents the shared secret. You probably should only look at it once, but you can enroll as many devices as you want at that time. As long as their clocks are synchronized they will generate the same codes. Yeah I think I misunderstood how the QR code worked. Essentially what I think we're going to do is just take the ASCII value of the QR code that AWS gives you when you set up MFA (lol acronyms) and store that in our secret vault. Anytime someone needs to log into the root AWS account, they will need to know the root creds as well as having that QR code loaded into their authenticator of choice. Thanks thread!
|
|
#
?
Sep 15, 2016 21:35
|
|
|
^^ The QR code is just a oauth key. You can use it many times. false edit - ah, just a second too late 
|
|
#
?
Sep 15, 2016 21:36
|
|
|
Novo posted:When I set up 2FA I always enroll both my phone and my tablet using the same QR code, in case one of them dies. The problem with a shared MFA stuck in a vault is that you can't revoke access to it necessarily if someone had access to it even after an emergency situation. You'll need a way to confirm or ensure rotation / revocation of existing MFA tokens as well if your security people are stringent. I had all my MFA keys after I left my last job and my account logins were all disabled once I lost access to my e-mail, but if it was your AWS root account you may not want to disable it completely outright (although AWS will tell you that you totally should go full hog IAM roles out the wazoo everywhere and don't bother using root accounts). Root account credentials for AWS accounts at my last place were stored at datacenters using HSM (there were over 90+ AWS accounts - not quite change between the couch cushions).
|
|
#
?
Sep 15, 2016 21:54
|
|
|
necrobobsledder posted:The problem with a shared MFA stuck in a vault is that you can't revoke access to it necessarily if someone had access to it even after an emergency situation. Not sure I understand why this is the case?
|
|
#
?
Sep 15, 2016 22:16
|
|
|
Internet Explorer posted:Not sure I understand why this is the case?
|
|
#
?
Sep 15, 2016 22:42
|
|
|
Sorry, I guess I am just not understanding. How does a hardware authentication token not give out one time use keys? Doesn't that defeat the purpose?
|
|
#
?
Sep 16, 2016 00:01
|
|
|
Internet Explorer posted:Sorry, I guess I am just not understanding. How does a hardware authentication token not give out one time use keys? Doesn't that defeat the purpose?
|
|
#
?
Sep 16, 2016 01:13
|
|
|
We solved this by making lookout accounts IAM for users in case our federated access fails. Our root account hardware device is kept in a safe alone with our root internal CA.
|
|
#
?
Sep 16, 2016 01:40
|
|
|
Hold the loving phone, google finally gets with the program. https://cloud.google.com/powershell/
|
|
#
?
Sep 16, 2016 18:37
|
|
|
incoherent posted:Hold the loving phone, google finally gets with the program. Hrm, if I have time/wherewithal for stuff I'll take a look at this to see whether it's poo poo/hot poo poo.
|
|
#
?
Sep 16, 2016 19:00
|
|
|
Just posting here to show off my new favorite shirt http://www.ctera.com
|
|
#
?
Sep 20, 2016 04:45
|
|
|
Let's say I want to have a working knowledge of cloud computing, and I'm coming from a place where I have no real technical experience. I'm just interested in learning more about the internet works. Sounds dumb, but I want to know. Where would I start?
|
|
#
?
Dec 19, 2016 17:36
|
|
|
AWS youtube tutorials. You can have a derpy little blog up and running in a few hours for little or no cost.
|
|
#
?
Dec 19, 2016 20:03
|
|
|
"How the internet works" is a really, really broad topic.
|
|
#
?
Dec 19, 2016 21:03
|
|
|
Admit it, you're just trying to start a nerd fight and watch the carnage, aren't you? That kind of post needs a trigger warning  "Cloud" can mean a bunch of different things, depending on context. Can you elaborate more about what level you really want to know about? Dragging and dropping goatse.jpg into Dropbox or hosting your email at Office 365 can be "cloud". Or using AWS/Azure/Google/OpenStack (lol) to dynamically scale your entire infrastructure on-demand in response to traffic can be cloud. It's a ridiculously huge spectrum of meaning and I'm guessing you only care about some portion.
|
|
#
?
Dec 19, 2016 21:28
|
|
|
Docjowles posted:Admit it, you're just trying to start a nerd fight and watch the carnage, aren't you? That kind of post needs a trigger warning Why I never...!
|
|
#
?
Dec 19, 2016 21:40
|
|
|
Haha, I actually meant Convexed
|
|
#
?
Dec 19, 2016 21:49
|
|
|
Docjowles posted:Haha, I actually meant Convexed Oh. Well then, I'm feeling defensive for absolutely no reason. None at all.
|
|
#
?
Dec 19, 2016 22:04
|
|
|
Convexed posted:Let's say I want to have a working knowledge of cloud computing, and I'm coming from a place where I have no real technical experience. I'm just interested in learning more about the internet works. Sounds dumb, but I want to know. Where would I start?
|
|
#
?
Dec 20, 2016 02:34
|
|
|
The other important part is "what do you know already that you think may or may not be relevant"? Secondly, do you even have an interest in those topics in the first place?
|
|
#
?
Dec 21, 2016 01:30
|
|
|
Convexed posted:Let's say I want to have a working knowledge of cloud computing, and I'm coming from a place where I have no real technical experience. I'm just interested in learning more about the internet works. Sounds dumb, but I want to know. Where would I start? http://shop.oreilly.com/product/9781565920637.do
|
|
#
?
Dec 21, 2016 01:34
|
|
|
I wonder when the internet stopped being so printable....
|
|
#
?
Dec 21, 2016 02:16
|
|
|
incoherent posted:I wonder when the internet stopped being so printable.... I actually have a physical copy of that book that I found cleaning out a storage closest at a previous job.
|
|
#
?
Dec 21, 2016 17:32
|
|
|
I definitely had some kind of "internet yellow pages" physical book in the late 90s. It was literally just like 300 pages listing every significant website that existed. The idea is hysterical now.
|
|
#
?
Dec 21, 2016 22:36
|
|
|
|
| # ? May 5, 2024 18:39 |
|
|
Docjowles posted:I definitely had some kind of "internet yellow pages" physical book in the late 90s. It was literally just like 300 pages listing every significant website that existed. The idea is hysterical now. I remember when Altavista was the best search engine and Yahoo was an actual index of sites grouped by category. I also remember having a SLIP account to play on a MUD and download an 0.99 kernel version of Slackware to put on floppies. I'd get a floppy image via FTP to my SLIP account, use Z-Modem to pull it down to my computer and then get the next one. It took about a week. When my ISP started offering PPP, it blew my mind.
|
|
#
?
Dec 21, 2016 22:46
|
|
