added service accounts targeting example

quality improvements
This commit is contained in:
savagebidoof 2023-04-22 08:17:23 +02:00
parent 8bd07817dd
commit d0751fcbf8
28 changed files with 477 additions and 650 deletions

View File

@ -1,71 +0,0 @@
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: root-default
# namespace: default
namespace: istio-system
spec:
# workloadSelector:
# labels:
# app: helloworld
egress:
- hosts:
- "./*"
# - "istio-system/*"
# ingress:
# - port:
# number: 8080
# protocol: HTTP
# name: ingressport
# defaultEndpoint: 127.0.0.1:80
---
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: helloworld-default
namespace: default
# namespace: istio-system
spec:
# workloadSelector:
# labels:
# app: helloworld
# egress:
# - port:
# number: 8080
# protocol: HTTP
# name: egresshttp
## - "internal.foo.svc.cluster.local"
# hosts:
# - "foo/*"
# - hosts:
# - "istio-system/*"
ingress:
- port:
number: 8080
protocol: HTTP
name: ingressport
defaultEndpoint: 127.0.0.1:80
---
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: internal-default
namespace: foo
spec:
workloadSelector:
labels:
app: internal
egress:
- hosts:
- "./*"
- "istio-system/*"
#- "wikipedia.com"
ingress:
# - hosts:
# - "./*"
# - "istio-system/*"
- port:
number: 8080
protocol: HTTP
name: myingressport
defaultEndpoint: 127.0.0.1:80

View File

@ -1,51 +0,0 @@
# Continues from
- 01-ingress-proxy-forwarding
# Description
This example configures the sidecar proxy on the pods created, to forward the traffic ongoing (egress)
- Configure egress to a different namespace?
> the configured meshconfig.rootNamespace namespace (istio-system by default)
https://istio.io/latest/docs/ops/best-practices/traffic-management/#cross-namespace-configuration
CANT MAKE IT WORK CANT MAKE IT WORK CANT MAKE IT WORK
istioctl install --set profile=default -y --set meshConfig.accessLogFile=/dev/stdout --set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY
---
kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}'
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- /bin/bash
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl internal.foo.svc.cluster.local
curl helloworld.default.svc.cluster.local
curl internal.foo.svc.cluster.local
curl: (6) Could not resolve host: internal.foo.svc.cluster.local
helloworld.default.svc.cluster.local:8080
kubectl exec -i -n foo -t "$(kubectl get pod -l app=internal -n foo | tail -n 1 | awk '{print $1}')" -- /bin/bash

View File

@ -1,5 +0,0 @@
spec:
meshConfig:
outboundTrafficPolicy:
mode: REGISTRY_ONLY
# Doesnt work

View File

@ -1,62 +0,0 @@
#apiVersion: networking.istio.io/v1beta1
#kind: Sidecar
#metadata:
# name: helloworld-default
# namespace: default
## namespace: istio-config
#spec:
## workloadSelector:
## labels:
## app: helloworld
## egress:
## - hosts:
## - "./*"
## - "istio-system/*"
# ingress:
# - port:
# number: 8080
# protocol: HTTP
# name: ingressport
# defaultEndpoint: 127.0.0.1:80
---
#apiVersion: networking.istio.io/v1alpha3
#kind: Sidecar
#metadata:
# name: helloworld-sidecar
#spec:
# workloadSelector:
# labels:
# app: helloworld
# ingress:
# - port:
# number: 8080
# protocol: HTTP
# name: ingressport
# defaultEndpoint: 127.0.0.1:80
#---
#apiVersion: networking.istio.io/v1beta1
#kind: Sidecar
#metadata:
# name: helloworld-default
# namespace: default
## namespace: istio-system
#spec:
# workloadSelector:
# labels:
# app: helloworld2
# egress:
# - port:
# number: 9080
# protocol: HTTP
# name: httpingress
# hosts:
# - "foo/*"
# - hosts:
# - "istio-system/*"
# ingress:
# - port:
# number: 8080
# protocol: HTTP
# name: ingressport
# defaultEndpoint: 127.0.0.1:80
#---

View File

@ -1,9 +0,0 @@
apiVersion: v1
kind: Namespace
metadata:
name: visiblent
labels:
# istio-injection: "false"
istio-injection: "enabled"
f: "3"
---

View File

@ -1,66 +0,0 @@
https://github.com/steren/istio.github.io/blob/master/_docs/setup/kubernetes/sidecar-injection.md
https://istio.io/latest/docs/reference/config/networking/sidecar/
# Continues from
- 01-hello_world_1_service_1_deployment
the labbel `workloadSelector` only affects the pods.
```yaml
workloadSelector:
```
whats this command again?
istioctl operator init
https://istio.io/latest/docs/ops/common-problems/injection/
```sh
kubectl create namespace istio-config
```
No fucking clue on how to make it NOT work.
https://istio.io/latest/blog/2021/discovery-selectors/#discovery-selectors-vs-sidecar-resource
https://istio.io/latest/docs/reference/config/networking/sidecar/
# Sidecar notes
Sidecar describes the configuration of the sidecar proxy that mediates inbound and outbound communication to the
workload instance it is attached to.
By default, Istio will program all sidecar proxies in the mesh with the necessary
configuration required to reach every workload instance in the mesh, as well as accept traffic on all the ports associated
with the workload.
The Sidecar configuration provides a way to fine tune the set of ports, protocols that the proxy will
accept when forwarding traffic to and from the workload. In addition, it is possible to restrict the set of services that
the proxy can reach when forwarding outbound traffic from workload instances.
The behavior of the system is undefined if two or more Sidecar configurations with a workloadSelector select the same workload instance.
https://youtu.be/lnYTqNfyzNk
https://www.youtube.com/watch?v=UJ86BNQEcTA

View File

@ -1,19 +0,0 @@
## https://github.com/istio/istio/blob/master/samples/helloworld/helloworld.yaml
#---
#apiVersion: networking.istio.io/v1alpha3
#kind: ServiceEntry
#metadata:
# name: external-svc
# namespace: visiblent
#spec:
# hosts:
# - help.websiteos.com
# # /websiteos/example_of_a_simple_html_page.htm
## - http://help.websiteos.com/websiteos/example_of_a_simple_html_page.htm
# ports:
# - number: 80
# name: http
# protocol: HTTP
# resolution: DNS
# location: MESH_EXTERNAL
#---

View File

@ -1,51 +0,0 @@
## https://github.com/istio/istio/blob/master/samples/helloworld/helloworld.yaml
apiVersion: v1
kind: Service
metadata:
name: helliworld
labels:
app: helloworld
service: helloworld
# namespace: visiblent
spec:
ports:
- port: 8080
name: http
selector:
app: helloworld
#---
#apiVersion: v1
#kind: ServiceAccount
#metadata:
# name: istio-helloworld
# labels:
# account:
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: helloworld-nginx
labels:
app: helloworld
# namespace: visiblent
spec:
replicas: 1
selector:
matchLabels:
app: helloworld
template:
metadata:
labels:
app: helloworld
# namespace: visiblent
spec:
# serviceAccountName: istio-helloworld
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent #Always
ports:
- containerPort: 80

View File

@ -1,64 +0,0 @@
# https://github.com/istio/istio/blob/master/samples/helloworld/helloworld-gateway.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: helloworld-gateway
spec:
selector:
istio: ingressgateway # use istio default controller
servers:
- port:
number: 80
name: http
protocol: HTTP
hosts:
- "*"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: helloworld-vs
spec:
hosts:
- "*"
gateways:
- helloworld-gateway
http:
- match:
- uri:
exact: /helloworld
route:
- destination:
host: helliworld
# host: helloworlddo
# host: helloworld-nginx-56c5c77cd7-9mxmf.visiblent
port:
number: 8080
rewrite:
uri: "/"
---
#apiVersion: networking.istio.io/v1alpha3
#kind: VirtualService
#metadata:
# name: helloworld-vs
#spec:
# hosts:
# - "*"
# gateways:
# - helloworld-gateway
# http:
# - timeout: 3s
# match:
# - uri:
# - exact: "/external"
# route:
# - destination:
# host: help.websiteos.com
# port:
# number: 80
# rewrite:
# uri: "/websiteos/example_of_a_simple_html_page.htm"
# headers:
# request:
# set:
# HOST: "help.websiteos.com"

View File

@ -1,47 +0,0 @@
## First we overide the default configuration.
# This configures the egress, to only allow egress within the same namespace, and to `istio-system`
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: default
namespace: istio-config
spec:
egress:
- hosts:
- "./*"
- "istio-system/*"
---
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: helloworlddo
# namespace: visiblent
spec:
workloadSelector:
labels:
app: helloworld
ingress:
# - bind: 192.168.1.50
# - bind: 172.17.121.220
- port:
number: 8080
protocol: HTTP
name: ingressport
defaultEndpoint: 127.0.0.1:80
# defaultEndpoint: unix:///var/run/someuds.sock
# captureMode: DEFAULT
# egress:
# - port:
# number: 80
# protocol: HTTP
# name: egressport
# hosts:
# - "prod-us1/*"
# - hosts:
# - "istio-system/*"
# egress:
# hosts:
# - "./*"
# - "istio-system/*"
# captureMode: DEFAULT

View File

@ -1,23 +0,0 @@
#apiVersion:
# networking.istio.io/v1alpha3
#kind: Sidecar
#metadata:
# name: default
# namespace: default
#spec:
# egress:
# - hosts:
# - "./*"
# - "istio-system/*"
#---
#apiVersion: networking.istio.io/v1alpha3
#kind: Sidecar
#metadata:
# name: default-sidecar
# namespace: default
#spec:
# egress:
# - hosts:
# - "default/*"
# - "istio-system/*"
# - "staging/*"

View File

@ -1,53 +0,0 @@
apiVersion: v1
kind: Service
metadata:
name: ratings
labels:
app: ratings
service: ratings
spec:
ports:
- port: 8443
name: https
targetPort: 80
selector:
app: ratings
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: ratings-peer-auth
namespace: prod-us1
spec:
selector:
matchLabels:
app: ratings
mtls:
mode: STRICT
portLevelMtls:
80:
mode: DISABLE
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: ratings
namespace: prod-us1
spec:
workloadSelector:
labels:
app: ratings
ingress:
- port:
number: 80
protocol: HTTPS
name: somename
defaultEndpoint: unix:///var/run/someuds.sock
tls:
mode: SIMPLE
privateKey: "/etc/certs/privatekey.pem"
serverCertificate: "/etc/certs/servercert.pem"

View File

@ -1,8 +0,0 @@
https://github.com/steren/istio.github.io/blob/master/_docs/setup/kubernetes/sidecar-injection.md
https://istio.io/latest/docs/reference/config/networking/sidecar/
# Continues from
- 01-hello_world_1_service_1_deployment

View File

@ -1,27 +0,0 @@
apiVersion:
networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: foo
spec:
egress:
- hosts:
- "./*"
- "istio-system/*"
---
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default-sidecar
namespace: default
spec:
workloadSelector:
labels:
version: v1
egress:
- hosts:
- "default/*"
- "istio-system/*"
- "staging/*"
---

View File

@ -1,11 +0,0 @@
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default-sidecar
namespace: default
spec:
egress:
- hosts:
- "default/*"
- "istio-system/*"
- "staging/*"

View File

@ -1,3 +1,8 @@
---
gitea: none
include_toc: true
---
# Continues from
[//]: # (- [01-hello_world_1_service_1_deployment](../../01-simple/01-hello_world_1_service_1_deployment))
@ -106,16 +111,14 @@ spec:
notPaths: ["/secret*"]
```
Citing the [`rule.source.namespaces` field from the Authorization Policy documentation from Istio](https://istio.io/latest/docs/reference/config/security/authorization-policy/#Source):
> This field requires mTLS enabled and is the same as the source.namespace attribute.
# Walkthrough
## Deploy the resources
```shell
$ kubectl apply -f ./
kubectl apply -f ./
```
```text
namespace/foo created
authorizationpolicy.security.istio.io/allow-nothing created
authorizationpolicy.security.istio.io/allow-nothing created
@ -136,7 +139,9 @@ virtualservice.networking.istio.io/helloworld-vs created
#### Get LB IP
```shell
$ kubectl get svc istio-ingressgateway -n istio-system
kubectl get svc istio-ingressgateway -n istio-system
```
```text
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.97.47.216 192.168.1.50 15021:31316/TCP,80:32012/TCP,443:32486/TCP 39h
```
@ -148,7 +153,9 @@ Due to the rule `allow-nothing` created on the namespace `default`, we are not h
For such we receive the status code `403` (**Forbidden**)
```shell
$ curl 192.168.1.50/helloworld -I
curl 192.168.1.50/helloworld -I
```
```text
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
@ -164,7 +171,9 @@ As we created the rule `allow-from-istio-system` created in the namespace `foo`,
For such we receive the code `200`.
```shell
$ curl 192.168.1.50/byeworld --head
curl 192.168.1.50/byeworld --head
```
```text
HTTP/1.1 200 OK
server: istio-envoy
date: Sat, 22 Apr 2023 02:01:48 GMT
@ -182,8 +191,10 @@ x-envoy-upstream-service-time: 91
> The command `curl`, when uses the flag `--head` or `-I`, the request sent will be a `HEAD` request.
>
> It's important to be aware of that due the rule configured, where one of the targets was the method used, specifically targeted the method `HEAD`.
>
> On this example, all request will be done with the method `HEAD` unless specified otherwise.
#### helloworld towards byeworld (HEAD REQUEST)
#### helloworld towards byeworld
It works.
@ -192,7 +203,9 @@ Due to the rule `allow-get-from-default` deployed on the namespace `foo`, which
```shell
$ kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090 --head
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090 --head
```
```text
HTTP/1.1 200 OK
server: envoy
date: Sat, 22 Apr 2023 02:08:56 GMT
@ -206,15 +219,16 @@ x-envoy-upstream-service-time: 6
#### helloworld towards byeworld (GET REQUEST)
(we removed the `--head` flag)
This example is made on base on the last comand executed, where the request sent uses the `HEAD` method.
It fails.
Due to the rule `allow-get-from-default` deployed on the namespace `foo`, which allowed the traffic coming from the namespace `default` as long it used the method `HEAD` and wasn't targeting the path `/secret`, the request is allowed.
On this example the flag `--head` is removed, which causes the command `curl` to send a request of method `GET`.
As the rule created required the method to be `HEAD`, it causes the request to not be allowed, and finally as there are no rules that allow this request, it results in failure.
```shell
$ kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090
```
```text
RBAC: access denied%
```
@ -227,7 +241,9 @@ As expected, like when accessing through the Load Balancer, we receive the statu
The `HEAD` request is irrelevant on this scenario, yet using it as I like this output more.
```shell
$ kubectl exec -i -n foo -t "$(kubectl get pod -n foo -l app=byeworld | tail -n 1 | awk '{print $1}')" -- curl http://helloworld.default.svc.cluster.local:8080 --head
kubectl exec -i -n foo -t "$(kubectl get pod -n foo -l app=byeworld | tail -n 1 | awk '{print $1}')" -- curl http://helloworld.default.svc.cluster.local:8080 --head
```
```text
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
@ -236,10 +252,16 @@ server: envoy
x-envoy-upstream-service-time: 65
```
#### helloworld towards byeworld/secret (HEAD REQUEST)
#### helloworld towards byeworld/secret
Due to the configuration set on the rule `allow-get-from-default`, one of the conditions for it to allow the traffic, was to not access the path/match the prefix expression `/secret*`.
This causes the traffic to not be allowed.
```shell
$ kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090/secret --head
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090/secret --head
```
```text
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
@ -251,38 +273,22 @@ x-envoy-upstream-service-time: 3
#### helloworld towards byeworld/not-found
On this example, we can notice how even if the request was allowed due meeting all the requirements, it still results in the error code `404` (Not Found).
This 404 error is raised by the destination service, yet before being able to handle such request, firstly the traffic required to be allowed, meaning that even if we target as a destination path a non-existent resource, we will need to match the requirements for the traffic to be allowed.
```shell
$ kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090/secret --head
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Sat, 22 Apr 2023 02:40:30 GMT
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090/not-found --head
```
```text
HTTP/1.1 404 Not Found
server: envoy
x-envoy-upstream-service-time: 3
date: Sat, 22 Apr 2023 06:09:59 GMT
content-type: text/html
content-length: 153
x-envoy-upstream-service-time: 67
```
---
## Delete the PeerAuthentication configuration set
```shell
$ kubectl delete peerauthentications.security.istio.io default-mtls
```
### connectivity between byeworld towards helloworld
As the rule is no longer being set, and for such not being applied, the traffic from `byeworld` is able to reach the service `helloworld` without having the need to use mTLS.
```shell
$ kubectl exec -i -t "$(kubectl get pod -l app=byeworld | tail -n 1 | awk '{print $1}')" -- curl http://helloworld.default.svc.cluster.local:8080 | grep "<title>.*</title>"
<title>Welcome to nginx!</title>
```
# Links of interest
- https://istio.io/latest/docs/reference/config/security/authorization-policy/

View File

@ -42,13 +42,4 @@ spec:
to:
- operation:
methods: ["HEAD"]
notPaths: ["/secret*"]
---
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
name: default-mtls
namespace: default
spec:
mtls:
mode: STRICT
notPaths: ["/secret*"]

View File

@ -0,0 +1,7 @@
apiVersion: v1
kind: ServiceAccount
metadata:
name: istio-helloworld-sa
labels:
app: helloworld
---

View File

@ -0,0 +1,338 @@
---
gitea: none
include_toc: true
---
# Continues from
[//]: # (- [01-hello_world_1_service_1_deployment]&#40;../../01-simple/01-hello_world_1_service_1_deployment&#41;)
- [01-namespaces](../01-namespaces)
> **Note:**\
> On this example there is minimal changes to the configuration to involve targeting service accounts.
## Description
Bla bla bla
Configuration targeting service accounts
By default, when a pod is deployed, if a service account has not been specified, it will be given the service account `default` from that namespace.
# Changelog
## Service Account
### default namespace
#### istio-helloworld-sa
Created a service account named `istio-helloworld-sa`.
The label was set cause it made sense, yet it's not used on this example.
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: istio-helloworld-sa
labels:
app: helloworld
```
## Authentication configuration deployed
### default namespace
#### Allow nothing
```yaml
# Deny all requests to namespace default
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: default
```
Citing the [Authorization Policy documentation from Istio](https://istio.io/latest/docs/reference/config/security/authorization-policy), regarding the evaluation behavior of these rules:
1. If there are any CUSTOM policies that match the request, evaluate and deny the request if the evaluation result is deny.
2. If there are any DENY policies that match the request, deny the request.
3. If there are no ALLOW policies for the workload, allow the request.
4. If any of the ALLOW policies match the request, allow the request.
5. Deny the request.
On this scenario, as we don't have any DENY or CUSTOM rule, we skip right into the 3rd scenario.
This rule is being applied to the workload (due being a rule that affects the whole namespace), and for such the 3rd scenario is not being applied either.
On the 4rth, scenario, as the rule deployed, even if it's on ALLOW mode, has no conditions, it won't allow the traffic either.
And finally, as any of the above scenarios allowed the traffic of the request, it ends getting denied.
For such, the creation of this "empty" rule, has set the authorization mode on the not explicitly allowed request to "DENY ALL".
### foo namespace
#### Allow nothing
Same behavior as above, this time applied to the namespace `foo`
```yaml
# Deny all requests to namespace foo
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: foo
spec:
{}
```
#### allow-from-istio-system
As we have a service deployed, and the traffic will come through the Istio Load Balancer (at least on my environment).
I have set a rule that will allow all the traffic coming from a resource located in the namespace `istio-system` AND also uses the service account `istio-ingressgateway-service-account` from that namespace.
```yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-from-istio-system
namespace: foo
spec:
action: ALLOW
rules:
- from:
- source:
namespaces: ["istio-system"]
- source:
principals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]
```
This service account is the account set to the ingress gateway resource currently set.
For reference, I have check it through the following command.
```shell
kubectl get pod -n istio-system istio-ingressgateway-864db96c47-mj5r2 -o jsonpath='{.spec.serviceAccount}'
```
```text
istio-ingressgateway-service-account%
```
#### allow-get-from-default
As an additional example, I have set a new rule, that will allow the traffic coming from the namespace `default`, as long the method used is `HEAD` and is not targeting the path `/secret`.\
Additionally, it requires that the requester uses the service account `istio-helloworld-sa` that we created.
```yaml
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-from-istio-system
namespace: foo
spec:
action: ALLOW
rules:
- from:
- source:
namespaces: ["default"]
- source:
principals: ["cluster.local/ns/default/sa/istio-helloworld-sa"]
to:
- operation:
methods: ["HEAD"]
notPaths: ["/secret*"]
```
Citing the [`rule.source.namespaces` field from the Authorization Policy documentation from Istio](https://istio.io/latest/docs/reference/config/security/authorization-policy/#Source):
> This field requires mTLS enabled and is the same as the source.namespace attribute.
# Walkthrough
## Deploy the resources
```shell
kubectl apply -f ./
```
```text
namespace/foo created
serviceaccount/istio-helloworld-sa created
authorizationpolicy.security.istio.io/allow-nothing created
authorizationpolicy.security.istio.io/allow-nothing created
authorizationpolicy.security.istio.io/allow-from-istio-system created
authorizationpolicy.security.istio.io/allow-head-from-default created
service/helloworld created
deployment.apps/helloworld-nginx created
service/byeworld created
deployment.apps/byeworld-nginx created
gateway.networking.istio.io/helloworld-gateway created
virtualservice.networking.istio.io/helloworld-vs created
```
## Test resources
### Curl / LB requests / requests from external traffic
#### Get LB IP
```shell
kubectl get svc istio-ingressgateway -n istio-system
```
```text
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
istio-ingressgateway LoadBalancer 10.97.173.231 192.168.1.50 15021:31277/TCP,80:30603/TCP,443:30290/TCP 34h
```
#### helloworld
Due to the rule `allow-nothing` created on the namespace `default`, we are not hitting any rule that explicitly allows us, and for such, the traffic is being denied.
For such we receive the status code `403` (**Forbidden**)
```shell
curl 192.168.1.50/helloworld -I
```
```text
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Sat, 22 Apr 2023 05:56:00 GMT
server: istio-envoy
x-envoy-upstream-service-time: 102
```
#### byeworld
We created the rule `allow-from-istio-system` created in the namespace `foo`, which allows all the traffic coming from a resource located in the namespace `istio-system`, and the load balancer used is located in the namespace `istio-system`.
On top of that, the Istio ingress being used, has the service account `istio-ingressgateway-service-account` from the namespace `istio-system` set, which is the current target of the rule.
For such we receive the code `200`.
```shell
curl 192.168.1.50/byeworld --head
```
```text
HTTP/1.1 200 OK
server: istio-envoy
date: Sat, 22 Apr 2023 06:01:00 GMT
content-type: text/html
content-length: 615
last-modified: Tue, 28 Mar 2023 15:01:54 GMT
etag: "64230162-267"
accept-ranges: bytes
x-envoy-upstream-service-time: 10
```
### Connectivity between the deployments
> **NOTE:**\
> The command `curl`, when uses the flag `--head` or `-I`, the request sent will be a `HEAD` request.
>
> It's important to be aware of that due the rule configured, where one of the targets was the method used, specifically targeted the method `HEAD`.
#### helloworld towards byeworld (HEAD REQUEST)
It works.
Due to the rule `allow-get-from-default` deployed on the namespace `foo`, which allowed the traffic coming from the namespace `default` as long it used the method `HEAD` and wasn't targeting the path `/secret`, and, the deployment `helloworld` being using the service account `istio-helloworld-sa`, which is the target configured on the network rule, the request is allowed.
```shell
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090 --head
```
```text
HTTP/1.1 200 OK
server: envoy
date: Sat, 22 Apr 2023 06:01:08 GMT
content-type: text/html
content-length: 615
last-modified: Tue, 28 Mar 2023 15:01:54 GMT
etag: "64230162-267"
accept-ranges: bytes
x-envoy-upstream-service-time: 4
```
#### helloworld towards byeworld (GET REQUEST)
This example is made on base on the last comand executed, where the request sent uses the `HEAD` method.
On this example the flag `--head` is removed, which causes the command `curl` to send a request of method `GET`.
As the rule created required the method to be `HEAD`, it causes the request to not be allowed, and finally as there are no rules that allow this request, it results in failure.
```shell
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090
```
```text
RBAC: access denied%
```
#### byeworld towards helloworld
It fails.
As expected, like when accessing through the Load Balancer, we receive the status code `403` (**Forbidden**).
The `HEAD` request is irrelevant on this scenario, yet using it as I like this output more.
```shell
kubectl exec -i -n foo -t "$(kubectl get pod -n foo -l app=byeworld | tail -n 1 | awk '{print $1}')" -- curl http://helloworld.default.svc.cluster.local:8080 --head
```
```text
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Sat, 22 Apr 2023 06:06:13 GMT
server: envoy
x-envoy-upstream-service-time: 99
```
#### helloworld towards byeworld/secret
Due to the configuration set on the rule `allow-get-from-default`, one of the conditions for it to allow the traffic, was to not access the path/match the prefix expression `/secret*`.
This causes the traffic to not be allowed.
```shell
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090/secret --head
```
```text
HTTP/1.1 403 Forbidden
content-length: 19
content-type: text/plain
date: Sat, 22 Apr 2023 06:15:38 GMT
server: envoy
x-envoy-upstream-service-time: 3
```
#### helloworld towards byeworld/not-found
On this example, we can notice how even if the request was allowed due meeting all the requirements, it still results in the error code `404` (Not Found).
This 404 error is raised by the destination service, yet before being able to handle such request, firstly the traffic required to be allowed, meaning that even if we target as a destination path a non-existent resource, we will need to match the requirements for the traffic to be allowed.
```shell
kubectl exec -i -t "$(kubectl get pod -l app=helloworld | tail -n 1 | awk '{print $1}')" -- curl http://byeworld.foo.svc.cluster.local:9090/not-found --head
```
```text
HTTP/1.1 404 Not Found
server: envoy
date: Sat, 22 Apr 2023 06:15:29 GMT
content-type: text/html
content-length: 153
x-envoy-upstream-service-time: 28
```
# Links of interest
- https://istio.io/latest/docs/reference/config/security/authorization-policy/

View File

@ -0,0 +1,50 @@
# Deny all requests to namespace foo
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: foo
spec:
{}
---
# Deny all requests to namespace default
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-nothing
namespace: default
spec:
{}
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-from-istio-system
namespace: foo
spec:
action: ALLOW
rules:
- from:
- source:
namespaces: ["istio-system"]
- source:
principals: ["cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account"]
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
name: allow-head-from-default
namespace: foo
spec:
action: ALLOW
rules:
- from:
- source:
namespaces: ["default"]
- source:
principals: ["cluster.local/ns/default/sa/istio-helloworld-sa"]
to:
- operation:
methods: ["HEAD"]
notPaths: ["/secret*"]
---

View File

@ -1,14 +1,15 @@
## https://github.com/istio/istio/blob/master/samples/helloworld/helloworld.yaml
apiVersion: v1
kind: Service
metadata:
name: helloworld
labels:
app: helloworld
service: helloworld
spec:
ports:
- port: 8080
name: http
targetPort: 80
selector:
app: helloworld
---
@ -28,12 +29,13 @@ spec:
labels:
app: helloworld
spec:
serviceAccountName: istio-helloworld-sa
containers:
- name: helloworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent #Always
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80

View File

@ -1,45 +1,43 @@
## https://github.com/istio/istio/blob/master/samples/helloworld/helloworld.yaml
apiVersion: v1
kind: Service
metadata:
name: internal
name: byeworld
labels:
app: internal
app: byeworld
service: byeworld
namespace: foo
spec:
ports:
- port: 8080
- port: 9090
name: http
- port: 80
name: http-default
targetPort: 80
selector:
app: internal
app: byeworld
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: internal
name: byeworld-nginx
labels:
app: internal
app: byeworld
namespace: foo
spec:
replicas: 1
selector:
matchLabels:
app: internal
app: byeworld
template:
metadata:
labels:
app: internal
service: apache
app: byeworld
# sidecar.istio.io/inject: "false"
spec:
containers:
- name: internal
image: httpd
- name: byeworld
image: nginx
resources:
requests:
cpu: "100m"
imagePullPolicy: IfNotPresent #Always
imagePullPolicy: IfNotPresent
ports:
- containerPort: 80

View File

@ -35,12 +35,11 @@ spec:
uri: "/"
- match:
- uri:
exact: /internal
exact: /byeworld
route:
- destination:
# host: helloworld.default.svc.cluster.local
host: internal.foo.svc.cluster.local
host: byeworld.foo.svc.cluster.local
port:
number: 8080
number: 9090
rewrite:
uri: "/"

View File

@ -1,16 +1,16 @@
## Authentication
- Between pods
- Based on deployments
- Between namespaces
- Based on namespaces (done)
- Based on method
- Based on method (somewhat done, so I will mark it as valid)
- Based on service account(s)
- Custom action (it's in alpha feature, should not focus on it for now)
- Audit / logs
- Audit / logs (shold be the 5th)
@ -23,4 +23,7 @@ https://discuss.istio.io/t/istio-deployment-deny-all-default/10983/6
- from:
- source:
principals: ["cluster.local/ns/default/sa/bookinfo-reviews"]
```
```
JWT seems important, refer to source.requestPrincipals