#security (2020-10)
Archive: https://archive.sweetops.com/security/
2020-10-14
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
![attachment image](https://blog.cloudflare.com/content/images/2020/10/facebook-shared-image.png)
Securely connecting your infrastructure to Cloudflare’s network just became easier.
![Igor avatar](https://avatars.slack-edge.com/2022-03-17/3244104166391_48a8db73944f03735a65_72.jpg)
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.
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
This is a rich space these days. Perimeter being just one of dozens.
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
The zero trust/beyondcorp model is more or less the gold standard today, with various vendors taking their own approach
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
Last week cloudflare launched “one”
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
Today HashiCorp announced boundary
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
What is your wire protocol for your apps?
![Igor avatar](https://avatars.slack-edge.com/2022-03-17/3244104166391_48a8db73944f03735a65_72.jpg)
For this use case, just https
![Igor avatar](https://avatars.slack-edge.com/2022-03-17/3244104166391_48a8db73944f03735a65_72.jpg)
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
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
So with IP whitelisting, is the single way of doing it with Security Groups, NACLs, WAF, ingress, or in the application?
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
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
![roth.andy avatar](https://avatars.slack-edge.com/2019-09-18/753707271651_6f58c1cbab3c77754f58_72.jpg)
Thought some might find this interesting. Was just approved for public release.
![Zach avatar](https://avatars.slack-edge.com/2020-07-21/1278358623280_e99d673db1471fc93095_72.jpg)
Got the source url handy?
![roth.andy avatar](https://avatars.slack-edge.com/2019-09-18/753707271651_6f58c1cbab3c77754f58_72.jpg)
it was emailed to me. hang on I’ll see if I can find it
![Zach avatar](https://avatars.slack-edge.com/2020-07-21/1278358623280_e99d673db1471fc93095_72.jpg)
oh ok I can search too in that case
![roth.andy avatar](https://avatars.slack-edge.com/2019-09-18/753707271651_6f58c1cbab3c77754f58_72.jpg)
Looks like it isn’t posted yet but a link to it will likely end up here: https://software.af.mil/dsop/documents/
![Zach avatar](https://avatars.slack-edge.com/2020-07-21/1278358623280_e99d673db1471fc93095_72.jpg)
yah was only finding the 2019 pre-release myself
![Zach avatar](https://avatars.slack-edge.com/2020-07-21/1278358623280_e99d673db1471fc93095_72.jpg)
thanks!
![andrey.a.devyatkin avatar](https://avatars.slack-edge.com/2020-10-15/1414538673559_734105299dec4a795ef1_72.jpg)
Thanks for sharing
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
![attachment image](https://www.cloudflare.com/resources/images/slt3lc6tev37/4BStkFSpWqZw4E3hykLD8F/8e1bbf2c6dcd9b94d041f81d98d8b2f9/twitter-shared-link.png)
Cloudflare Browser Isolation works with your native browser to protect remote teams and make web browsing safer and faster.
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
CF sniffs you TLS request, your DNS requests and now your clicks
![attachment image](https://www.cloudflare.com/resources/images/slt3lc6tev37/4BStkFSpWqZw4E3hykLD8F/8e1bbf2c6dcd9b94d041f81d98d8b2f9/twitter-shared-link.png)
Cloudflare Browser Isolation works with your native browser to protect remote teams and make web browsing safer and faster.
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
![attachment image](https://blog.cloudflare.com/content/images/2020/10/facebook-link-image-12.png)
Today, we’re excited to open up a beta of a third approach to keeping web browsing safe with Cloudflare Browser Isolation.
2020-10-21
2020-10-22
2020-10-27
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
Blog on beyondcorp (using lots of cloudposse modules as always): https://transcend.io/blog/restrict-access-to-internal-websites-with-beyondcorp
Made it to number 3 on hackernews today which makes me pretty happy
![btai avatar](https://avatars.slack-edge.com/2019-09-04/736463433650_34701761239ea7ba8207_72.jpg)
anyone have a quick an easy way to integrate OIDC w/ a static s3 site?
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html
Learn how to configure an Application Load Balancer to authenticate users of your applications using their corporate or social identities before routing requests.
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
IdP (Cognito, Okta, GSuite, etc.) -> ALB -> CloudFront -> S3
![btai avatar](https://avatars.slack-edge.com/2019-09-04/736463433650_34701761239ea7ba8207_72.jpg)
thank you @Andriy Knysh (Cloud Posse)
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
@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 ?
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
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)
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
Yeah however it is possible to decouple it so the current app doesn’t need modification?
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
Sort of instead of using http basic auth, use and IdP at the ALB level
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
oly if you place some kind of a proxy in front of the app
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
the proxy will do it
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
To redirect to the correct branch?
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
I have been trying this the whole day without much success
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
Do you know any example or blog source with shows this method?
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
Or at least the Keywords for Google
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
Thank you!
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
there are many ways of doing it
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
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
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
in which case each app must be deployed with k8s RBAC
![Andriy Knysh (Cloud Posse) avatar](https://avatars.slack-edge.com/2018-06-13/382332470551_54ed1a5d986e2068fd9c_72.jpg)
![attachment image](https://d2908q01vomqb2.cloudfront.net/ca3512f4dfa95a03169c5a670a4c91a19b3077b4/2019/12/22/landingpage-1260x630.jpg)
Amazon Elastic Kubernetes Service (Amazon EKS) authenticates users against IAM before they’re granted access to an EKS cluster. Access to each cluster is controlled by the aws-auth ConfigMap, a file that maps IAM users/roles to Kubernetes RBAC groups. In this guest post from Josh Van Leeuwen from Jetstack, we look at how we can use […]
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
We currently only authenticate company users with gSuite. Thus the external IdP
![btai avatar](https://avatars.slack-edge.com/2019-09-04/736463433650_34701761239ea7ba8207_72.jpg)
@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.
![btai avatar](https://avatars.slack-edge.com/2019-09-04/736463433650_34701761239ea7ba8207_72.jpg)
I can’t remember off the top of my head but I ran into a roadblock attempting to use ALB OIDC for my solution.
![rei avatar](https://secure.gravatar.com/avatar/707f916d5733af8f0ce7938695a8da03.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0005-72.png)
@btai thx for the hint. We’ll keep in mind. However we decided now to go for the vpn + internal alb/nlb solution
2020-10-28
2020-10-29
![Erik Osterman (Cloud Posse) avatar](https://secure.gravatar.com/avatar/88c480d4f73b813904e00a5695a454cb.jpg?s=72&d=https%3A%2F%2Fa.slack-edge.com%2Fdf10d%2Fimg%2Favatars%2Fava_0023-72.png)
On Monday, Oct. 27, KrebsOnSecurity began following up on a tip from a reliable source that an aggressive Russian cybercriminal gang known for deploying ransomware was preparing to disrupt information technology systems at hundreds of hospitals, clinics and medical care facilities across the United States. Today, officials from the FBI and the U.S. Department of…