IBM/portieris 226
A Kubernetes Admission Controller for verifying image trust with Notary.
A plugin for uptime that allows notifications to be sent to www.pagerduty.com
Lab steps for session 2406 at think 2019
bainsy88/Ibm-Containers-Labs-Denmark 0
Labs and tutorials used for IBM Containers, a hosted Docker-based container service on IBM Bluemix.
molepigeon/COM1019-Coursework 0
COM1019 Group Coursework, Spring 2011
Coursework for Advanced Challenges in Web Technologies
Email alert tool using Node.js on Bluemix.
A Node.js clock, useful for containers demos
PR opened IBM/portieris
Make it clearer that 0.8.1 drops support for Helm 2
pr created time in 2 days
push eventIBM/portieris
commit sha 2b0592a61e4bb2a6be27bf8e5fb8cd6129cb243b
Provide option to run out of cluster
commit sha f1a42fc2942f2041f876da445b12d9b9122e2d24
Merge pull request #186 from lucaspalm/out_of_cluster_config Provide option to run out of cluster
push time in 3 days
PR merged IBM/portieris
The changes here will give users the ability to install Portieris in an "out-of-cluster" configuration. It uses the KUBECONFIG env var to specify the kubeconfig for the cluster Portieris needs to manage. The in-cluster configuration that exists today will still function like normal when there is no KUBECONFIG env var set.
If choosing to run Portieris in an out-of-cluster configuration, these are the required changes/steps you would need to take:
- ensure KUBECONFIG env var is defined in Portieris runtime and it points to a valid kubeconfig file location
- ensure the tls certs are available at
/etc/certsin new runtime location - expose Portieris such that it is reachable from the kubernetes apiserver
- change the MutatingWebhookConfiguration to point to your new Portieris URL
Resolves https://github.com/IBM/portieris/issues/180
pr closed time in 3 days
issue closedIBM/portieris
Support out-of-cluster configuration
Right now, Portieris is installed directly inside the kubernetes cluster in which it manages. It would be great if Portieris had the option to run outside of the cluster as well.
Example out-of-cluster go-client configuration can be seen here.
As long as Portieris is fed the correct cluster Kubeconfig, it should be able to perform the same actions as it does today from within the cluster. The MutatingWebhookConfiguration ClientConfig could then be changed to point directly to the URL of the out-of-cluster Portieris instance. Docs on how that is done are here.
All other kube resources like webhooks, roles, policies, etc. would still be created in the kube cluster as normal.
closed time in 3 days
lucaspalm
push eventIBM/portieris
commit sha 5aee8f25715540b7da516b831412f40db4d9f8a9
Prepare for 0.8.1 release and minor fixes to e2e tests to accommodate previous rename of default cluster image policy.
commit sha 02dec7c537bd57b756384ae6881276c37339357a
Merge pull request #183 from IBM/prep081 Prepare for 0.8.1 release
push time in 13 days
PR merged IBM/portieris
and minor fixes to e2e tests to accommodate previous rename of default cluster image policy.
pr closed time in 13 days
push eventIBM/portieris
commit sha 8e31a42b7e89d8dc5b0cc4a4ec81c0e226ddb92d
Assign a weighting to namespace pre-install Higher in priority than serviceaccount
commit sha b3f61c14b16d1da50464f01724d8eec9a52d7efe
Merge pull request #182 from IBM/namespaceWeight Assign a weighting to namespace pre-install
push time in 13 days
PR merged IBM/portieris
Higher in priority than serviceaccount Fixes https://github.com/IBM/portieris/issues/181
pr closed time in 13 days
issue closedIBM/portieris
namespace needs to be created before serviceaccount in pre-install
<!-- Stop! Wait! Are you submitting a security issue? Don't report it here, email [email protected] instead! -->
<!-- Make sure to write a helpful title that accurately describes your problem! -->
What commit ID of Portieris did you experience the problem with?
ea1cc032649b8c1f7edd81920e7bbc61e7b55604
What went wrong?
Helm install failed because the pre-install failed to create the serviceaccount - due to the namespace not existing yet. Creating the namespace in advance caused the namespace pre-install to fail (because it already existed).
What should have happened differently?
Weightings should ensure that the namespace creation happens before the serviceaccount creation
How can it be reproduced?
make helm.install
Any other relevant information
closed time in 13 days
jhart1685
push eventIBM/portieris
commit sha a348fb705fc2a7dc1d15901a0aac4cf3231eb1e4
Make test should not return 0 if there are failed tests
commit sha e4c2e45048569cae8fa1de94187f28b0fc318dc2
Merge pull request #177 from IBM/prChecker Make test should not return 0 if there are failed tests
push time in 15 days
issue closedIBM/portieris
PR checker does not fail when it should
PR check should fail if unit tests fail
make test exits with 0 always
closed time in 15 days
sjhx
issue commentIBM/portieris
Fixed by https://github.com/IBM/portieris/pull/176
comment created time in 15 days
issue closedIBM/portieris
When we first launched, Helm didn't support a number of things that we needed, like creating custom resource definitions. So we created a number of Jobs in the chart that spun up a kubectl pod to apply yamls against the cluster.
I believe that the things we need are now supported, and so we can revisit the chart and try to create them in-line rather than spin up a kubectl pod. This would improve the experience when the chart fails to install, since there won't be jobs lying around that prevent you from re-running the chart installation.
closed time in 15 days
molepigeon
push eventIBM/portieris
commit sha 8e29f8c81ce6d4004af5f0d62ac8625a8e2b5b9a
Use a namespace selector for admission webhook (#145) * Use a namespace selector for admission webhook This prevents the webhook from being called for the Portieris install namespace, which means that Portieris can recover itself in the case of cluster failure. Without this an approval from the Portieris webhook is needed to okay scaling itself up. This means that with no pods available, the webhook can't approve the recovery of any Portieris pods, and so the cluster deadlocks. This change gives the Portieris chart ownership of the portieris install namespace, and labels it in such a way that we can filter for it in the webhook config. It's configured as an opt out, rather than Istio's which is an opt in. All namespaces without the label are fair game. By adding the namespace into the chart, it'll be deleted by Helm when the chart gets removed. And adding the label selector means that the label could be added to other namespaces to bypass Portieris. Both of these potential issues have been documented in the readme. https://github.com/IBM/portieris/issues/112 * Add an install option to skip annotated namespaces And docs to help people decide whether they want it. * Switch admissionskip to off by default
commit sha e90345091f7b0de1239486e10380d0ae1f94408d
Merge branch 'master' into notes
push time in 15 days
Pull request review commentIBM/portieris
Portieris is installed in your cluster. -Default security policies are installed in your cluster. You can modify the default policies or replace them with your own. For more information, see http://ibm.biz/cise_default.+You should update the policies according your your local requirements, for more information see https://github.com/IBM/portieris/blob/master/POLICIES.md
Repeated word: "according your your local requirements"
Possibly this was intended to say "according to your local requirements"?
comment created time in 15 days
pull request commentIBM/portieris
Use a namespace selector for admission webhook
I like the idea of the ID but I don't think it would be obscure enough. Anyone with the ability to read a namespace with the annotation could get it from the namespace itself.
I've come round to the idea of having the label selector off by default as long as we document enabling it as part of the install process, which I believe I've done.
comment created time in 15 days
push eventIBM/portieris
commit sha 7b12f9575060bec7605c972294a3cd9c01971e51
Update chart for Helm 3 compatibility * Removed the Hyperkube jobs that created the CRDs, admission webhooks, and default policies, in favour of the native support in Helm 3. * Migrated the CRD definition to apiextensions/v1 * Admission webhook will migrate to admissionregistration/v1 if it is supported, otherwise it stays at v1beta1 With this commit, the chart is no longer compatible with Helm 2, since Helm 2 does not support CRDs in the same way as Helm 3. It also requires Kube 1.16+ for the v1 CRD API. Updated the README to reflect this. https://github.com/IBM/portieris/issues/89 Signed-off-by: Michael Hough <[email protected]>
commit sha fbac065b77fd5b0d398a7f102ef7c22ca80d3b9c
Merge branch 'master' of github.com:IBM/portieris into helm3
commit sha 5c44acbc083b3e14a77f29a84cd438a98e37f5b6
Update policies.yaml no policy required for hyperkube since no longer run
commit sha fff23755aeed3e685bcad14c22e1a24ca8a98649
revert to v1beta crd/webhook
commit sha 85b52535ae613a365c864438f3438cecad3be6d7
Merge branch 'helm3' of github.com:IBM/portieris into helm3
commit sha 10385ccf68c6035a5b9ed3899e0e8c6d307f46f8
workstation/cluster
commit sha 6e533927583b722143c26b7bab9c8b1075472568
remove refs to hyperkube
commit sha e27fdef1dc1df4e7da1452f4ccb5e248d34ffa9e
Merge pull request #176 from IBM/helm3 Update chart for Helm 3 compatibility
commit sha 0ce8e33d8224354a4557f8ea159f898674d362d7
Use a namespace selector for admission webhook This prevents the webhook from being called for the Portieris install namespace, which means that Portieris can recover itself in the case of cluster failure. Without this an approval from the Portieris webhook is needed to okay scaling itself up. This means that with no pods available, the webhook can't approve the recovery of any Portieris pods, and so the cluster deadlocks. This change gives the Portieris chart ownership of the portieris install namespace, and labels it in such a way that we can filter for it in the webhook config. It's configured as an opt out, rather than Istio's which is an opt in. All namespaces without the label are fair game. By adding the namespace into the chart, it'll be deleted by Helm when the chart gets removed. And adding the label selector means that the label could be added to other namespaces to bypass Portieris. Both of these potential issues have been documented in the readme. https://github.com/IBM/portieris/issues/112
commit sha 1d2df540ecf6e5bee4524162939379a56f3d9f55
Add an install option to skip annotated namespaces And docs to help people decide whether they want it.
commit sha cf291cc1e78cec454a202a8ba75516015ba9031d
Switch admissionskip to off by default
push time in 15 days
push eventIBM/portieris
commit sha 7b12f9575060bec7605c972294a3cd9c01971e51
Update chart for Helm 3 compatibility * Removed the Hyperkube jobs that created the CRDs, admission webhooks, and default policies, in favour of the native support in Helm 3. * Migrated the CRD definition to apiextensions/v1 * Admission webhook will migrate to admissionregistration/v1 if it is supported, otherwise it stays at v1beta1 With this commit, the chart is no longer compatible with Helm 2, since Helm 2 does not support CRDs in the same way as Helm 3. It also requires Kube 1.16+ for the v1 CRD API. Updated the README to reflect this. https://github.com/IBM/portieris/issues/89 Signed-off-by: Michael Hough <[email protected]>
commit sha fbac065b77fd5b0d398a7f102ef7c22ca80d3b9c
Merge branch 'master' of github.com:IBM/portieris into helm3
commit sha 5c44acbc083b3e14a77f29a84cd438a98e37f5b6
Update policies.yaml no policy required for hyperkube since no longer run
commit sha fff23755aeed3e685bcad14c22e1a24ca8a98649
revert to v1beta crd/webhook
commit sha 85b52535ae613a365c864438f3438cecad3be6d7
Merge branch 'helm3' of github.com:IBM/portieris into helm3
commit sha 10385ccf68c6035a5b9ed3899e0e8c6d307f46f8
workstation/cluster
commit sha 6e533927583b722143c26b7bab9c8b1075472568
remove refs to hyperkube
commit sha e27fdef1dc1df4e7da1452f4ccb5e248d34ffa9e
Merge pull request #176 from IBM/helm3 Update chart for Helm 3 compatibility
push time in 15 days
PR merged IBM/portieris
- Removed the Hyperkube jobs that created the CRDs, admission webhooks, and default policies, in favour of the native support in Helm 3.
- ~Migrated the CRD definition to apiextensions/v1~
- ~Admission webhook will migrate to admissionregistration/v1 if it is supported, otherwise it stays at v1beta1~
With this commit, the chart is no longer compatible with Helm 2, since Helm 2 does not support CRDs in the same way as Helm 3. It also requires Kube 1.16+ for the v1 CRD API. Updated the README to reflect this.
https://github.com/IBM/portieris/issues/89
Signed-off-by: Michael Hough [email protected]
pr closed time in 15 days
Pull request review commentIBM/portieris
Update chart for Helm 3 compatibility
webhooks: apiVersions: ["*"] resources: ["pods", "deployments", "replicationcontrollers", "replicasets", "daemonsets", "statefulsets", "jobs", "cronjobs"] failurePolicy: Fail-{{ end }}+ sideEffects: None+ admissionReviewVersions: ["v1beta1"]
These look fine but can we double-check by running the e2e tests against this branch?
comment created time in 15 days
pull request commentIBM/portieris
Use a namespace selector for admission webhook
As it is currently, the cluster is more secure in terms of integrity but less so in availability. If Portieris deadlocks a cluster, it can turn a seconds-long outage into a much longer one while engineers get paged out and have to work out why their cluster isn't recovering.
I think it's reasonable to expect that an operator who's concerned about what's running in their cluster enough to install Portieris would also be familiar with RBAC policies and be using them in anger. If they weren't doing so and everyone had cluster-admin, someone could use that access to uninstall Portieris, so we already rely on proper RBAC configuration to prevent that.
If a cluster operator prevents users from annotating a namespace or from installing other deployments into the Portieris namespace, the skip annotation wouldn't be exploitable without privilege escalation. If an attacker can elevate their privilege they may also be able to delete the Portieris webhook anyway. The normal operating mode of the cluster would be secure, while also allowing Portieris to recover.
I think the default configuration should be least friction for getting started, with clear instructions on how to configure it, and users can choose to add friction later if they need it for their use case. We've taken this approach already with the default policies - currently everything is allowed in default or kube-system until the user changes the policies.
comment created time in a month
push eventIBM/portieris
commit sha 7c9a2090253c9c938f794f36aeb4578f98cd9359
Delete ISSUE_TEMPLATE
push time in a month
push eventIBM/portieris
commit sha 78c0c0bc400c543466fa40cf2ed7522d4ee1c3c7
Update issue templates Add feature request issue template
push time in a month
pull request commentIBM/portieris
Use a namespace selector for admission webhook
I've pushed another commit that adds the option.
On consideration, I think it's easier to prevent people you don't trust from annotating namespaces than it is to hope that you never have an outage of all your nodes, so I've defaulted it to allowing the skip annotation to work.
comment created time in a month
push eventIBM/portieris
commit sha e1dc918ef742b08074892c1f1212216dce384f96
Revise default policies (#140) * 1st pass * resolve #95 * policies: names / own image / redundant nil * words * comment typo * consistently remove redundant policy and space
commit sha cf2902f3e55556885abd96cf54e17390e3f34c85
Set service protocol appropriately (#149) * Set service protocol appropriately The Portieris server is a HTTPS one, but we were saying it was HTTP in the service. This incorrect protocol reportedly breaks Istio's proxying of TLS requests. * Update CHANGELOG.md Co-authored-by: Stuart Hayton <[email protected]>
commit sha 6a39389eb63fc37123e74a2c522d53fac93fd44c
--purge has been removed from helm 3 The default behavior is to --purge and if you want to retain your history you now need to explicitly use, when deleting/uninstalling, --keep-history
commit sha 897f9f1add548d8a2e3eee4c0bfdea7e3b374aa7
Update POLICIES.md Provide instruction on creating KeySecrets
commit sha 09319ff6c288cae56722758b62c49cfad7fb8835
Update POLICIES.md quotes and such
commit sha 91779260c99555ce1aea0290398ae55687def524
tag specifc policy denies upgrade
commit sha be9ddb0eac546a31afc4c6a1fb42358ce201e448
Release proc (#164) * prepare to release * diag help * Create RELEASE-HOWTO.md * Update Makefile * Update Chart.yaml * Update values.yaml
commit sha dffd167f19816bb8d79d36603630243c3814e501
Adding creating secret example (#154) * Revert "--purge has been removed from helm 3" * Adding creating secret example In setting this up using the latest feature of look-aside signatures, last week, I spent a few hours trying to understand how the secret should have been created - particularly the name of the key it was looking for. Naming it anything other than 'key' would not work. By default, i believe it picks up the basename of the file. Either way, adding an example for clarity. Lastly, when I was trying to figure out how to configure for look-aside, I could not find anything relevant to the statement mentioning 'KeyType' and removed it. The literal word 'KeyType' does not show anywhere in the doc and it was a little confusing to read. * Update README.md * Update POLICIES.md Co-authored-by: Stuart Hayton <[email protected]>
commit sha c384818f5da6b2ded7c6d870cf5613b6e9127cec
adjust helm usage - optimize/adjust docs (#152) * adjust helm usage - optimize/adjust docs since we're using helm 3, allow it to create the namespace for us. adjust the documentation, on deleting, as helm delete will not find the release if not in the 'default' namespace. Additionally, notify user that any created namespaces are not cleaned up on a helm delete. * Update cleanup.sh Co-authored-by: Stuart Hayton <[email protected]>
commit sha 1bfe736d161b46872de7db7396cddb53d05a837d
cant use + in a tag (#165) * cant use + in a tag * Update README.md
commit sha ceaa5ab87f7de74c92bf4ffeb2240e339915a0a2
Allow anonymous notary access (#159) Co-authored-by: Stuart Hayton <[email protected]>
commit sha 850f87db866a4ab8816ebecadc66c52b8c6ec6fa
Use cert-manager naming convention for portieris (#147) * Use cert-manager naming convention for portieris Rename portieris certs from serverCert.pem and serverKey.pem to tls.crt and tls.key, following the naming conventions used by cert-manager. In combination with SkipSecretCreation=true, this allows using cert-manager to generate portieris certs. https://github.com/IBM/portieris/issues/59 Signed-off-by: Joseph Richard <[email protected]> * Add UseCertManager option to get CA certificate This commit adds an option in the admission webhook, to support getting the CA certificate through injection from the cert-manager webhook, instead of being passed into the helm chart as a file. https://github.com/IBM/portieris/issues/59 Signed-off-by: Joseph Richard <[email protected]> * Create certificate by default if UseCertManager https://github.com/IBM/portieris/issues/59 Signed-off-by: Joseph Richard <[email protected]> * Add optionally using cert-manager to readme https://github.com/IBM/portieris/issues/59 Signed-off-by: Joseph Richard <[email protected]> Co-authored-by: Stuart Hayton <[email protected]>
commit sha a8dbe388cfc88a80de183fc6eeb64b551491508f
Use a namespace selector for admission webhook This prevents the webhook from being called for the Portieris install namespace, which means that Portieris can recover itself in the case of cluster failure. Without this an approval from the Portieris webhook is needed to okay scaling itself up. This means that with no pods available, the webhook can't approve the recovery of any Portieris pods, and so the cluster deadlocks. This change gives the Portieris chart ownership of the portieris install namespace, and labels it in such a way that we can filter for it in the webhook config. It's configured as an opt out, rather than Istio's which is an opt in. All namespaces without the label are fair game. By adding the namespace into the chart, it'll be deleted by Helm when the chart gets removed. And adding the label selector means that the label could be added to other namespaces to bypass Portieris. Both of these potential issues have been documented in the readme. https://github.com/IBM/portieris/issues/112
commit sha 0c6b857d76cd8c4257e974dea08cbac146b744be
Add an install option to skip annotated namespaces And docs to help people decide whether they want it.
push time in a month
push eventIBM/portieris
commit sha 91779260c99555ce1aea0290398ae55687def524
tag specifc policy denies upgrade
push time in a month
PR merged IBM/portieris
pr closed time in a month
push eventIBM/portieris
commit sha 897f9f1add548d8a2e3eee4c0bfdea7e3b374aa7
Update POLICIES.md Provide instruction on creating KeySecrets
commit sha 09319ff6c288cae56722758b62c49cfad7fb8835
Update POLICIES.md quotes and such
push time in 2 months
PR merged IBM/portieris
Provide instruction on creating KeySecrets
pr closed time in 2 months
issue commentIBM/portieris
can't visit link in Readme It is like a black page
Hi, that link works for me, it goes to a section called "Controlling who can customize policies" in the IBM Cloud docs.
Try clearing your cache and cookies or try a different browser.
If you can access the IBM Cloud docs through Google search results, you can search for "ibm cloud docs container image security enforcement" and the first result (for me) is a topic called "Enforcing container image security - IBM Cloud" which contains the section that the link points to.
comment created time in 2 months
push eventIBM/portieris
commit sha 6a39389eb63fc37123e74a2c522d53fac93fd44c
--purge has been removed from helm 3 The default behavior is to --purge and if you want to retain your history you now need to explicitly use, when deleting/uninstalling, --keep-history
push time in 2 months
PR merged IBM/portieris
The default behavior is to --purge and if you want to retain your history you now need to explicitly use, when deleting/uninstalling, --keep-history
pr closed time in 2 months
PR opened IBM/portieris
The Portieris server is a HTTPS one, but we were saying it was HTTP in the service. This incorrect protocol reportedly breaks Istio's proxying of TLS requests.
pr created time in 2 months
push eventIBM/portieris
commit sha e1dc918ef742b08074892c1f1212216dce384f96
Revise default policies (#140) * 1st pass * resolve #95 * policies: names / own image / redundant nil * words * comment typo * consistently remove redundant policy and space
push time in 3 months
PR merged IBM/portieris
update installed policies in line with https://github.com/IBM/portieris/issues/94 fix https://github.com/IBM/portieris/issues/95
pr closed time in 3 months
issue closedIBM/portieris
imagepolicy incorrect in portieris namespace / if portieris pulled from docker.io
When the portieris image is in docker.io the policy becomes
- name: /portieris:0.6.0 policy: null
with a leading / so will fail to match, template issue.
closed time in 3 months
sjhx
PR opened IBM/portieris
This prevents the webhook from being called for the Portieris install namespace, which means that Portieris can recover itself in the case of cluster failure.
Without this an approval from the Portieris webhook is needed to okay scaling itself up. This means that with no pods available, the webhook can't approve the recovery of any Portieris pods, and so the cluster deadlocks.
This change gives the Portieris chart ownership of the portieris install namespace, and labels it in such a way that we can filter for it in the webhook config.
It's configured as an opt out, rather than Istio's which is an opt in. All namespaces without the label are fair game.
By adding the namespace into the chart, it'll be deleted by Helm when the chart gets removed. And adding the label selector means that the label could be added to other namespaces to bypass Portieris. Both of these potential issues have been documented in the readme.
https://github.com/IBM/portieris/issues/112
pr created time in 3 months
PR closed IBM/portieris
Configured to run if anything is different from the labels on the Portieris pods themselves
https://github.com/IBM/portieris/issues/112
pr closed time in 3 months
pull request commentIBM/portieris
Add objectSelector for portieris webhook
Nah. This is a super bad idea, anyone could just match the labels on a deployment in a namespace where they're allowed to deploy and skip the webhook.
comment created time in 3 months
PR opened IBM/portieris
Configured to run if anything is different from the labels on the Portieris pods themselves
https://github.com/IBM/portieris/issues/112
pr created time in 3 months