Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document RBAC set up for ingress key cert protection. #755

Merged
merged 9 commits into from
Feb 6, 2018

Conversation

JimmyCYJ
Copy link
Member

@JimmyCYJ JimmyCYJ commented Dec 5, 2017

Which issue this PR fixes: fixes istio/old_auth_repo#313

Copy link
Contributor

@wattli wattli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this. Generally looks good with a few comments.

@@ -269,6 +269,344 @@ rules.
curl -I -k https://$INGRESS_HOST/status/200
```

## Configuring RBAC for ingress key/cert
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The key/cert is only used in above section, would it make more sense to put the new content in that section?

@@ -269,6 +269,344 @@ rules.
curl -I -k https://$INGRESS_HOST/status/200
```

## Configuring RBAC for ingress key/cert
There are service accounts which can access this ingress key/cert, and the ingress key/cert is not
encrypted. This leads to risks of leaking key/cert. We can set up Role-Based Access Control ("RBAC")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not accurate. K8s supports encrypted secret already, see here: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ . It would be great if we could update this as well. But maybe in a follow up PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for pointing that out. I didn't know that we can encrypt secret. I will document encrypting secrets in a follow up PR.

istio-ingress-service-account. We need to update or replace these RBAC set up to only allow
istio-ingress-service-account to access ingress key/cert.

1. Update RBAC set up for istio-pilot-service-account and istio-mixer-istio-service-account.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please help to keep the new content succinct and only display things of interest.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have made the content shorter now.

```
This produces the following output:

```bash
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have to display everything, please focus on ingress related one.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done. Thanks!

metadata:
name: istio-pilot-mixer-istio-system
rules:
- apiGroups: [""] # "" indicates the core API group
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here and below. Please avoid showing unrelated content.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@JimmyCYJ JimmyCYJ force-pushed the rbac-ingress-key-cert branch from 3228b41 to bd00f69 Compare December 5, 2017 19:35
@JimmyCYJ
Copy link
Member Author

JimmyCYJ commented Dec 5, 2017

I have revised the document, please take a look. Thanks.

```bash
kubectl delete ClusterRoleBinding istio-pilot-admin-role-binding-istio-system
kubectl delete ClusterRoleBinding istio-mixer-admin-role-binding-istio-system
kubectl delete ClusterRole istio-mixer-istio-system
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a similar role for istio-pilot-istio-system?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there any way to recover the deletion here at the end of this file? The idea is to clean up the change in this file after everything is done.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And what privileges will pilot/mixer lose after this change? I am afraid this will break existing system. Let me add some pilot and mixer guy.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

istio-pilot-istio-system is also bound to account istio-ingress-service-account by istio-ingress-admin-role-binding-istio-system. We will delete istio-pilot-istio-system in next step, after deleting that ClusterRoleBinding object.

According to https://github.com/istio/istio/blob/11dc2fb937a23157215fffa06921cf507d27f757/install/kubernetes/istio.yaml#L22
istio-pilot-istio-system grants access permission to many resources. We need to bind those rules to istio-pilot-service-account. We should apply similar role binding process to account istio-mixer-service-account and istio-ca-service-account

NAME TYPE DATA AGE
istio-ca-secret istio.io/ca-root 2 7d
istio-ingress-certs kubernetes.io/tls 2 7d
istio-ingress-service-account-token-kwr85 kubernetes.io/service-account-token 3 7d
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we remove this one as well? And istio-ca-secret?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["secrets"]
resourceNames: ["istio-ca-service-account-token-rl4xm"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems quite dangerous to hard-code names with randomized tokens (rl4xm).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a kubernetes.io/service-account-token, and it is removed.

namespace: istio-system
- kind: ServiceAccount
name: istio-mixer-service-account
namespace: istio-system
Copy link
Member

@lookuptable lookuptable Dec 6, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we're binding the same role to both mixer SA and pilot SA. Is this desirable? IIRC mixer and pilot need different permissions.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, they need different permissions. I have create separate ClusterRoles for each of them.

```

Create istio-pilot-mixer-istio-system.yaml, which allows istio-pilot-service-account and
istio-mixer-service-account to read all kubernetes.io/service-account-token,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think anyone needs to read kubernetes.io/service-account-token, no?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. That line is removed.

@ldemailly
Copy link
Member

can we move this forward, it's been open a while ? (and there is a conflict to be resolved now too)

@JimmyCYJ
Copy link
Member Author

Sure, I will update this PR.

@ldemailly
Copy link
Member

ping ?

@JimmyCYJ
Copy link
Member Author

JimmyCYJ commented Feb 3, 2018

Sorry I was working on other stuff, will update this PR soon.

Copy link
Member

@ldemailly ldemailly left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we should update the installation rather than document workarounds ?

@@ -214,11 +214,6 @@ The following are the known limitations of Istio ingress:
kubectl get ingress secure-ingress -o wide
```

```bash
NAME HOSTS ADDRESS PORTS AGE
secure-ingress * 130.211.10.121 80 1d
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this sample output removed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That part is added back. Thanks.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR is for the ingress controller task only. Maybe we can update the installation with a more general solution in future work?

@JimmyCYJ JimmyCYJ force-pushed the rbac-ingress-key-cert branch from ea6c3b3 to 5795f37 Compare February 6, 2018 03:07
@wattli
Copy link
Contributor

wattli commented Feb 6, 2018

Please validate it before submission. Thanks for working on this, Jimmy.

Copy link
Contributor

@wattli wattli left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm

@ldemailly ldemailly merged commit ea11fcf into istio:master Feb 6, 2018
@JimmyCYJ JimmyCYJ deleted the rbac-ingress-key-cert branch February 6, 2018 21:11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

RBAC setup for ingress key/cert
4 participants