ferricoxide<p><span>The joys of being a </span><a href="https://evil.social/tags/CLI" rel="nofollow noopener" target="_blank">#CLI</a><span> guy in a world full of (web) </span><a href="https://evil.social/tags/GUI" rel="nofollow noopener" target="_blank">#GUI</a><span> users…<br><br>So, I'm now working on a newish (to me) project that's based on </span><a href="https://evil.social/tags/AWS" rel="nofollow noopener" target="_blank">#AWS</a><span>. Customer's dev-to-prod topology is set up through a few dozen accounts. Each of the accounts is its own authentication-domain. Each account's webUI has a 1-hour timeout for login credentials. Each account's CLI credentials have a multi-hour timeout. <br><br>I'm a CLI-first kind of guy, and the AWS webUI's session-management is kind of ass: if you're logged in to one account, you can't really be logged into another in the same browser profile. By itself, not a problem, since I mostly use the CLI utilities and each terminal session can maintain a wholly-separate login session to AWS.<br><br>One of the customer's programs that I wrote some </span><a href="https://evil.social/tags/terraform" rel="nofollow noopener" target="_blank">#terraform</a><span> for was having issues connecting directly to their RDS from their remote-desktop hosts. I got pinged on Slack to take a look and try to figure out what's wrong. <br><br>I do a quick query of the RDS's security group and see no rules indicating that the security group </span><i><span>should</span></i><span> allow access. The PM who pinged me to help the customer-user, is barking that he sees the access-exception in the GUI. "Cool: I'm not seeing what you're seeing in the CLI".<br><br>Ultimately, it turns out that the customer-user had attached a security-group to the RDS and added her ingress rule </span><i><span>there</span></i><span>. As designed, the RDS was only supposed to have a single RDS attached to it and any modifications should have happened </span><i><span>there</span></i><span>. PM gets cranky that I'm making too many assumptions and that I should ignore my automation …never mind that the automation was supposed to be how people deploy/modify RDSes and associated objects. I point out to the PM that, at no time in the conversation, did anyone say "I added a security group and made my changes there", just "I made changes". I further point out that the webUI's view on things can often be the result of a compound query and that I can make a similar query, but only if someone provides me enough information that I know to do so. Ultimately, I was able to see what the customer-user had done by executing:<br></span></p><pre><code>aws ec2 describe-security-groups \
--query 'SecurityGroups[].IpPermissions[].{
CIDRS:IpRanges[].CidrIp,
Groups:UserIdGroupPairs[].GroupId
}' \
--group-id $(
aws rds describe-db-instances \
--query 'DBInstances[].VpcSecurityGroups[].VpcSecurityGroupId' \
--filters 'Name=db-instance-id,Values=' \
--output text
) --output text</code></pre><span><br>Ultimately, it turned out that the customer-user had added invalid CIDRs to her ingress rules. I wouldn't have been able to help with that, any way, since I have no idea what CIDRs were correct for where she was attempting to connect from. However, once the PM provided the updated CIDRs and she updated her ingress-rules, all was good to go.<br><br>Still: exceedingly frustrating getting yelled at for, essentially, not being a fucking mind-reader.</span><p></p>