#security (2020-10)
Archive: https://archive.sweetops.com/security/
2020-10-14
As a provider, IP Whitelisting is still the main way that firewall exceptions are made to us by our customers to access their protected applications. Is there a better solution to this use case than VPN? I’ve looked at Perimeter81, but I am not sold on the whole approach.
This is a rich space these days. Perimeter being just one of dozens.
The zero trust/beyondcorp model is more or less the gold standard today, with various vendors taking their own approach
Last week cloudflare launched “one”
Today HashiCorp announced boundary
What is your wire protocol for your apps?
For this use case, just https
I think that’s part of the problem. Everyone is going to be implementing their flavor of zero-trust and we’ll have to jump through hoops to set up our connectivity as opposed to having a single way of doing it with something universal like IP Whitelisting/VPN client
So with IP whitelisting, is the single way of doing it with Security Groups, NACLs, WAF, ingress, or in the application?
So HTTP is the ideal case and perhaps the most demonstrated case for how to expose apps in the zero trust model with IAP (identity aware proxies). It’s more or less synonymous to VPNs. A VPN will require a user to identify and login. It then creates a point to point connection with the VPN server and sends layer 3 or 4 traffic over it. Then additional firewall rules and subnet routing policies need to be used to protect services from the VPN traffic.
In the IAP model, you have a point to point TCP connection (just like with the VPN). You’re speaking one wire protocol (HTTP), unlike with the VPN it can be anything. You identifying with Single Sign On (e.g. works well with Okta, Gsuite, etc). The proxy connects you to exactly one service, not the entire network so there’s no need for additional firewalling and routing rules.
2020-10-15
Thought some might find this interesting. Was just approved for public release.
Got the source url handy?
it was emailed to me. hang on I’ll see if I can find it
oh ok I can search too in that case
Looks like it isn’t posted yet but a link to it will likely end up here: https://software.af.mil/dsop/documents/
yah was only finding the 2019 pre-release myself
thanks!
Thanks for sharing
CF sniffs you TLS request, your DNS requests and now your clicks
2020-10-21
2020-10-22
2020-10-27
anyone have a quick an easy way to integrate OIDC w/ a static s3 site?
IdP (Cognito, Okta, GSuite, etc.) -> ALB -> CloudFront -> S3
thank you @Andriy Knysh (Cloud Posse)
@Andriy Knysh (Cloud Posse) It is possible to use this scheme to authenticate and authorize users with an IdP at the ALB and allow access to infinite apps under https://<branch_slug>.dev.mydomain.com ?
ALB can authenticate access to all apps on the cluster. Authorization is a completely separate thing. Each app will get a list of actions that the user can perform (a list of roles for example). It’s the app’s task to do the authorization (allow or disallow the user access)
Yeah however it is possible to decouple it so the current app doesn’t need modification?
Sort of instead of using http basic auth, use and IdP at the ALB level
oly if you place some kind of a proxy in front of the app
the proxy will do it
To redirect to the correct branch?
I have been trying this the whole day without much success
Do you know any example or blog source with shows this method?
Or at least the Keywords for Google
Thank you!
there are many ways of doing it
at the cluster/namespace level,
Access to each cluster is controlled by the aws-auth ConfigMap, a file that maps IAM users/roles to Kubernetes RBAC groups
in which case each app must be deployed with k8s RBAC
We currently only authenticate company users with gSuite. Thus the external IdP
@rei i had this same exact problem that I wanted to solve. I ended up building a very small oidc reverse proxy that sits as sidecar in the ingress controller pod. So it looks like this: ALB -> oidc sidecar -> ingress controller -> service
Then we set up the oidc sidecar to cache the session as a wildcard cookie (*.[mydomain.com](http://mydomain.com)) with an expiration set at 1 day.
I can’t remember off the top of my head but I ran into a roadblock attempting to use ALB OIDC for my solution.
@btai thx for the hint. We’ll keep in mind. However we decided now to go for the vpn + internal alb/nlb solution