Skip to content

Commit

Permalink
Merge pull request #3 from IBM/cleanup
Browse files Browse the repository at this point in the history 
Added minikube example
  • Loading branch information
@mrsabath
mrsabath authored Jan 14, 2020
2 parents 7469654 + 6742b01 commit 1720f10
Show file tree
Hide file tree
Showing 22 changed files with 228 additions and 283 deletions.
183 changes: 4 additions & 179 deletions CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -89,9 +89,10 @@ make all -C examples/jwt-client/
make all -C examples/jwt-server/
```

## TI Key Release Helm Deployment
The deployment is done in `trusted-identity` namespace. If you are testing or developing
the code and execute the deployment several time, it is a good idea to cleanup the namespace before executing another deployment.
## TSI Helm Deployment
The deployment is done in `trusted-identity` namespace. If you are testing or
developing the code and execute the deployment several times, it is a good idea
to cleanup the namespace before executing another deployment.

Update [init-namespace.sh](./init-namespace.sh) per instructions above.
Run cleanup first, then init to initialize the namespace. This would remove all
Expand Down Expand Up @@ -132,179 +133,3 @@ and it is ready deploy.
To be consistent, move the newly created chart package into `charts` directory.

Once the helm charts are created, you can proceed with [install](./REAMDE.md#install-trusted-service-identity-framework) of the Trusted Service Identity framework

## Automate Vault Certificates
Optionally, Trusted Service Identity can additionally create a unique set of a
certificate and private key that is automatically registered with Vault service.
The certificates with x509v3 extended attributes are enclosed in the claims in the tokens.
The difference is that these certificates are not set to have a short expiry.
Once the pod is removed, the certificates would be revoked from the Vault.
In order to use this feature, one time host setup is required. See below.

### Deploy TI Setup

Get the default chart values and replace them with your private keys and certs.
Replace X.X.X with proper version numbers

```console
helm inspect values charts/ti-setup-X.X.X.tgz > config.yaml
# modify config.yaml with your own values
helm install charts/ti-setup-X.X.X.tgz --values=config.yaml --debug --name ti-setup
```

Once the `ti-setup` is successfully deployed, remove it.
```console
helm delete --purge ti-setup
```

To validate and inspect the values assigned by the setup chart, run the daemonset to access all the hosts:

```console
kubectl create -f examples/inspect-daemonset.yaml
kubectl get pods
# select the node that you like to inspect and get inside:
kubectl exec -it <pod_id> /bin/bash
# review /host/ti/secrets, /etc/machineid, /keys/
```

To remove/reset all the values setup by the `ti-setup` chart, run the following:

```console
kubectl create -f examples/cleanup-daemonset.yaml
kubectl delete -f examples/cleanup-daemonset.yaml
```

### Install TI with `Create Vault Certificate` option turned on
After the initial host setup is complete, execute the TI Helm install.
Make sure the `ti-key-release-1.createVaultCert=true`. This can be done
either via CLI:

```console
helm install charts/ti-key-release-2-X.X.X.tgz --debug --name tsi-install \
--set ti-key-release-1.cluster.name=ti-fra02 \
--set ti-key-release-1.cluster.region=eu-de \
--set ingress.host=ti-fra02.eu-de.containers.appdomain.cloud \
--set ti-key-release-1.createVaultCert=true
```
or by modifying the configuration values:
```
helm inspect values charts/ti-key-release-2-X.X.X.tgz > config.yaml
# modify config.yaml with ti-key-release-1.createVaultCert=true
helm install -i --values=config.yaml tsi-install charts/ti-key-release-2-X.X.X.tgz
```

# OLD DOCUMENTATION. It might not be relevant anymore...

## Create your own private key and public JSON Web Key Set (JWKS)
Before enabling the JWT policy in Istio, you need to first create a private key
and JWKS. The following steps are based on [this doc](https://github.com/istio/istio/blob/release-1.0/security/tools/jwt/samples/README.md)
This can be done from inside the sidecar container:

```console
kubectl -n trusted-identity exec -it <my_ubuntu_pod_id> -c jwt-sidecar /bin/bash
# generate private key using openssl
openssl genrsa -out key.pem 2048
# run gen-jwt.py with --jkws to create new public key set (JWKS) and sample JWT
python gen-jwt.py key.pem -jwks=./jwks.json --expire=60 --claims=foo:bar > demo.jwt
```

Preserve the newly created `key.pem` and `jwks.json`. Put the public JWKS to publicly accessible place e.g.
https://raw.githubusercontent.com/mrsabath/jwks-test/master/jwks.json in public GITHUB: https://github.com/mrsabath/jwks-test/blob/master/jwks.json

Put the private key to [./charts/ti-key-release-2/values.yaml](./charts/ti-key-release-2/values.yaml)

```yaml

ti-key-release-1:
jwtkey: |-
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAtRcoFKRhV5+1w3r9ZrDeT4XKaREaher2dAfg0i82Te2QG1B5
. . . .
***** MY KEY *****
. . . .
Au57AoGALTlcO/AMzyj/UjE+/6wP0nYuw90FitYq9h9q9jSYIMyxwQWJa4qWwkp9
0vuUNDqsbzFeqqG55f0FZp3bfmNExNs0igdcTzwfqt6Q4LGkZVFYicbshIxHDC0a
fn3/DuZcMg+chQ970y+XF5JtUwgVbYfaMiP1zrF0J6Fh4rHk3Cw=
-----END RSA PRIVATE KEY-----
```
Then redeploy the charts and your container.
# Trusted Identity with Istio
In this demo we will start a web service with Istio Envoy, enable Istio policy
to require JWT tokens to communicate with this service, then start a container with
corresponding sidecar to manage creation of JWT tokens. Only the tokens created by
a sidecar will be accepted by the Envoy. All other requests will be rejected.
For simplicity, we will use the same namespace for all the transactions.
## Start a web service with Istio Envoy
Use provided [examples/web-service.yaml] service for deployment with a sidecar:
```console
kubectl apply -n trusted-identity -f <(./istioctl kube-inject -f examples/web-service.yaml)
```

## Enable the JWT policy for Istio
In order to use the JWT tokens to authenticate the end-user, enable Istio policy
referencing prebuilt public key from [here](https://raw.githubusercontent.com/mrsabath/jwks-test/master/jwks.json)
To use your own set of keys, see instructions at the bottom of this page

```yaml
apiVersion: "authentication.istio.io/v1alpha1"
kind: "Policy"
metadata:
name: "jwt-example"
spec:
targets:
- name: web-service
origins:
- jwt:
issuer: "wsched@us.ibm.com"
jwksUri: "https://raw.githubusercontent.com/mrsabath/jwks-test/master/jwks.json"
principalBinding: USE_ORIGIN
```
Install the policy [examples/jwt-policy-example.yaml](./examples/jwt-policy-example.yaml)
```console
kubectl create -f examples/jwt-policy-example.yaml -n trusted-identity
```

## Testing the JWT token created by the sidecar
Every container created in `trusted-identity` namespace that conforms to [this
policy](./charts/ti-key-release-1/templates/cti-policy-example.yaml) gets a sidecar
that is creating JWT tokens as defined by `execute-get-key.sh` in [here](./components/jwt-sidecar/execute-get-key.sh)
This newly created token is available to the main container via shared mount (`/jwt-tokens/token`)

For testing purposes the sidecar creates a token valid 30 seconds and the refresh
rate is 25 seconds, so the application gets a new token 5 seconds before the old
one expires.

If you don't have the container running from previous steps, start it now:
```
console
kubectl -n trusted-identity create -f examples/myubuntu_inject.yaml
```

Login to this container and try to execute a connection to the web service.

```console
kubectl -n trusted-identity get pods
kubectl -n trusted-identity exec -it <my_ubuntu_pod_id> -c myubuntu /bin/bash

root@myubuntu-767584864-b76f8:/# curl web-service
Origin authentication failed.
root@myubuntu-767584864-b76f8:/#
```

Since we enabled the Istio policy, the web service's Envoy requires valid JWT token
to be provided in order to grant access to the server, so now let's try to connect
with newly created JWT token:

```console
# run endless loop to test the connection
while true; do curl --header "Authorization: Bearer $(cat /jwt-tokens/token)" web-service -s -w "%{http_code}\n";sleep 5; done
```
Now you should be getting valid web service responses
You can copy the JWT token from /jwt-tokens/token and inspect it (e.g. [https://jwt.io/](https://jwt.io/))
77 changes: 77 additions & 0 deletions MAINTAINERS.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
# Maintainers Guide

This guide is intended for maintainers - anybody with commit access to Trusted
Service Identity repository.

[Maintainers List](./MAINTAINERS.md##maintainers-list)

## Methodology

This repository does not have a traditional release management cycle, but
should instead be maintained as a useful, working, and polished reference at
all times. While all work can therefore be focused on the master branch, the
quality of this branch should never be compromised.

The remainder of this document details how to merge pull requests to the
repositories.

## Merge approval

The project maintainers use LGTM (Looks Good To Me) in comments on the pull
request to indicate acceptance prior to merging. A change requires LGTMs from
two project maintainers. If the code is written by a maintainer, the change
only requires one additional LGTM.

## Reviewing Pull Requests

We recommend reviewing pull requests directly within GitHub. This allows a
public commentary on changes, providing transparency for all users. When
providing feedback be civil, courteous, and kind. Disagreement is fine, so long
as the discourse is carried out politely. If we see a record of uncivil or
abusive comments, we will revoke your commit privileges and invite you to leave
the project.

During your review, consider the following points:

### Does the change have positive impact?

Some proposed changes may not represent a positive impact to the project. Ask
whether or not the change will make understanding the code easier, or if it
could simply be a personal preference on the part of the author (see
[bikeshedding](https://en.wiktionary.org/wiki/bikeshedding)).

Pull requests that do not have a clear positive impact should be closed without
merging.

### Do the changes make sense?

If you do not understand what the changes are or what they accomplish, ask the
author for clarification. Ask the author to add comments and/or clarify test
case names to make the intentions clear.

At times, such clarification will reveal that the author may not be using the
code correctly, or is unaware of features that accommodate their needs. If you
feel this is the case, work up a code sample that would address the pull
request for them, and feel free to close the pull request once they confirm.

### Does the change introduce a new feature?

For any given pull request, ask yourself "is this a new feature?" If so, does
the pull request (or associated issue) contain narrative indicating the need
for the feature? If not, ask them to provide that information.

Are new unit tests in place that test all new behaviors introduced? If not, do
not merge the feature until they are! Is documentation in place for the new
feature? (See the documentation guidelines). If not do not merge the feature
until it is! Is the feature necessary for general use cases? Try and keep the
scope of any given component narrow. If a proposed feature does not fit that
scope, recommend to the user that they maintain the feature on their own, and
close the request. You may also recommend that they see if the feature gains
traction among other users, and suggest they re-submit when they can show such
support.

## Maintainers List
IBM Research:
* Mariusz Sabath - [@mrsabath](https://github.com/mrsabath) - sabath@us.ibm.com
* Brandon Lum - [@lumjjb](https://github.com/lumjjb) - Brandon.Lum@ibm.com
* Daniel Pittner - [@dpittner](https://github.com/dpittner) - DPITTNER@de.ibm.com
Loading

0 comments on commit 1720f10

Please sign in to comment.