profile
viewpoint
Michael Hough molepigeon IBM Winchester, UK

IBM/portieris 226

A Kubernetes Admission Controller for verifying image trust with Notary.

Samze/uptime-pagerduty 3

A plugin for uptime that allows notifications to be sent to www.pagerduty.com

molepigeon/think-2406-lab 2

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

molepigeon/COM3014 0

Coursework for Advanced Challenges in Web Technologies

molepigeon/hursleyalerts 0

Email alert tool using Node.js on Bluemix.

molepigeon/nodeclock 0

A Node.js clock, useful for containers demos

create barnchIBM/portieris

branch : molepigeon-patch-1-1

created branch time in 2 days

PR opened IBM/portieris

Clarify Helm 3 items in 0.8.1 release

Make it clearer that 0.8.1 drops support for Helm 2

+1 -1

0 comment

1 changed file

pr created time in 2 days

create barnchIBM/portieris

branch : molepigeon-patch-1

created branch time in 2 days

push eventIBM/portieris

Lucas Palm

commit sha 2b0592a61e4bb2a6be27bf8e5fb8cd6129cb243b

Provide option to run out of cluster

view details

Michael Hough

commit sha f1a42fc2942f2041f876da445b12d9b9122e2d24

Merge pull request #186 from lucaspalm/out_of_cluster_config Provide option to run out of cluster

view details

push time in 3 days

PR merged IBM/portieris

Provide option to run out of cluster

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/certs in 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

+29 -4

2 comments

1 changed file

lucaspalm

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
PullRequestReviewEvent
PullRequestReviewEvent

delete branch IBM/portieris

delete branch : prep081

delete time in 13 days

push eventIBM/portieris

James Hart

commit sha 5aee8f25715540b7da516b831412f40db4d9f8a9

Prepare for 0.8.1 release and minor fixes to e2e tests to accommodate previous rename of default cluster image policy.

view details

Michael Hough

commit sha 02dec7c537bd57b756384ae6881276c37339357a

Merge pull request #183 from IBM/prep081 Prepare for 0.8.1 release

view details

push time in 13 days

PR merged IBM/portieris

Prepare for 0.8.1 release

and minor fixes to e2e tests to accommodate previous rename of default cluster image policy.

+17 -12

0 comment

8 changed files

jhart1685

pr closed time in 13 days

PullRequestReviewEvent

push eventIBM/portieris

James Hart

commit sha 8e31a42b7e89d8dc5b0cc4a4ec81c0e226ddb92d

Assign a weighting to namespace pre-install Higher in priority than serviceaccount

view details

Michael Hough

commit sha b3f61c14b16d1da50464f01724d8eec9a52d7efe

Merge pull request #182 from IBM/namespaceWeight Assign a weighting to namespace pre-install

view details

push time in 13 days

PR merged IBM/portieris

Assign a weighting to namespace pre-install

Higher in priority than serviceaccount Fixes https://github.com/IBM/portieris/issues/181

+1 -0

0 comment

1 changed file

jhart1685

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 alchreg@uk.ibm.com 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
PullRequestReviewEvent

delete branch IBM/portieris

delete branch : prChecker

delete time in 15 days

push eventIBM/portieris

Alex Naylor

commit sha a348fb705fc2a7dc1d15901a0aac4cf3231eb1e4

Make test should not return 0 if there are failed tests

view details

Michael Hough

commit sha e4c2e45048569cae8fa1de94187f28b0fc318dc2

Merge pull request #177 from IBM/prChecker Make test should not return 0 if there are failed tests

view details

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
PullRequestReviewEvent
MemberEvent

issue commentIBM/portieris

Revisit jobs in helm chart

Fixed by https://github.com/IBM/portieris/pull/176

molepigeon

comment created time in 15 days

issue closedIBM/portieris

Revisit jobs in helm chart

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

Michael Hough

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

view details

Michael Hough

commit sha e90345091f7b0de1239486e10380d0ae1f94408d

Merge branch 'master' into notes

view details

push time in 15 days

PullRequestReviewEvent

Pull request review commentIBM/portieris

revise wrong reference

 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"?

sjhx

comment created time in 15 days

PullRequestReviewEvent
PullRequestReviewEvent

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.

molepigeon

comment created time in 15 days

push eventIBM/portieris

Michael Hough

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 <michaelh@uk.ibm.com>

view details

Stuart Hayton

commit sha fbac065b77fd5b0d398a7f102ef7c22ca80d3b9c

Merge branch 'master' of github.com:IBM/portieris into helm3

view details

Stuart Hayton

commit sha 5c44acbc083b3e14a77f29a84cd438a98e37f5b6

Update policies.yaml no policy required for hyperkube since no longer run

view details

Stuart Hayton

commit sha fff23755aeed3e685bcad14c22e1a24ca8a98649

revert to v1beta crd/webhook

view details

Stuart Hayton

commit sha 85b52535ae613a365c864438f3438cecad3be6d7

Merge branch 'helm3' of github.com:IBM/portieris into helm3

view details

Stuart Hayton

commit sha 10385ccf68c6035a5b9ed3899e0e8c6d307f46f8

workstation/cluster

view details

Stuart Hayton

commit sha 6e533927583b722143c26b7bab9c8b1075472568

remove refs to hyperkube

view details

Michael Hough

commit sha e27fdef1dc1df4e7da1452f4ccb5e248d34ffa9e

Merge pull request #176 from IBM/helm3 Update chart for Helm 3 compatibility

view details

Michael Hough

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

view details

Michael Hough

commit sha 1d2df540ecf6e5bee4524162939379a56f3d9f55

Add an install option to skip annotated namespaces And docs to help people decide whether they want it.

view details

Michael Hough

commit sha cf291cc1e78cec454a202a8ba75516015ba9031d

Switch admissionskip to off by default

view details

push time in 15 days

delete branch IBM/portieris

delete branch : helm3

delete time in 15 days

push eventIBM/portieris

Michael Hough

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 <michaelh@uk.ibm.com>

view details

Stuart Hayton

commit sha fbac065b77fd5b0d398a7f102ef7c22ca80d3b9c

Merge branch 'master' of github.com:IBM/portieris into helm3

view details

Stuart Hayton

commit sha 5c44acbc083b3e14a77f29a84cd438a98e37f5b6

Update policies.yaml no policy required for hyperkube since no longer run

view details

Stuart Hayton

commit sha fff23755aeed3e685bcad14c22e1a24ca8a98649

revert to v1beta crd/webhook

view details

Stuart Hayton

commit sha 85b52535ae613a365c864438f3438cecad3be6d7

Merge branch 'helm3' of github.com:IBM/portieris into helm3

view details

Stuart Hayton

commit sha 10385ccf68c6035a5b9ed3899e0e8c6d307f46f8

workstation/cluster

view details

Stuart Hayton

commit sha 6e533927583b722143c26b7bab9c8b1075472568

remove refs to hyperkube

view details

Michael Hough

commit sha e27fdef1dc1df4e7da1452f4ccb5e248d34ffa9e

Merge pull request #176 from IBM/helm3 Update chart for Helm 3 compatibility

view details

push time in 15 days

PR merged IBM/portieris

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 michaelh@uk.ibm.com

+9 -319

0 comment

16 changed files

sjhx

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?

sjhx

comment created time in 15 days

PullRequestReviewEvent
PullRequestReviewEvent

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.

molepigeon

comment created time in a month

PullRequestReviewEvent
PullRequestReviewEvent

push eventIBM/portieris

Michael Hough

commit sha 7c9a2090253c9c938f794f36aeb4578f98cd9359

Delete ISSUE_TEMPLATE

view details

push time in a month

push eventIBM/portieris

Michael Hough

commit sha 78c0c0bc400c543466fa40cf2ed7522d4ee1c3c7

Update issue templates Add feature request issue template

view details

push time in a month

PR opened IBM/portieris

Update issue templates

Add feature request issue template

+42 -0

0 comment

2 changed files

pr created time in a month

create barnchIBM/portieris

branch : molepigeon-patch-6

created branch 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.

molepigeon

comment created time in a month

push eventIBM/portieris

Stuart Hayton

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

view details

Michael Hough

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 <sjhx@users.noreply.github.com>

view details

IsThisTheMatrix

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

view details

Stuart Hayton

commit sha 897f9f1add548d8a2e3eee4c0bfdea7e3b374aa7

Update POLICIES.md Provide instruction on creating KeySecrets

view details

Stuart Hayton

commit sha 09319ff6c288cae56722758b62c49cfad7fb8835

Update POLICIES.md quotes and such

view details

Stuart Hayton

commit sha 91779260c99555ce1aea0290398ae55687def524

tag specifc policy denies upgrade

view details

Stuart Hayton

commit sha be9ddb0eac546a31afc4c6a1fb42358ce201e448

Release proc (#164) * prepare to release * diag help * Create RELEASE-HOWTO.md * Update Makefile * Update Chart.yaml * Update values.yaml

view details

IsThisTheMatrix

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 <sjhx@users.noreply.github.com>

view details

IsThisTheMatrix

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 <sjhx@users.noreply.github.com>

view details

Stuart Hayton

commit sha 1bfe736d161b46872de7db7396cddb53d05a837d

cant use + in a tag (#165) * cant use + in a tag * Update README.md

view details

Jeff Bachtel

commit sha ceaa5ab87f7de74c92bf4ffeb2240e339915a0a2

Allow anonymous notary access (#159) Co-authored-by: Stuart Hayton <sjhx@users.noreply.github.com>

view details

Joseph Richard

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 <joseph.richard@windriver.com> * 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 <joseph.richard@windriver.com> * Create certificate by default if UseCertManager https://github.com/IBM/portieris/issues/59 Signed-off-by: Joseph Richard <joseph.richard@windriver.com> * Add optionally using cert-manager to readme https://github.com/IBM/portieris/issues/59 Signed-off-by: Joseph Richard <joseph.richard@windriver.com> Co-authored-by: Stuart Hayton <sjhx@users.noreply.github.com>

view details

Michael Hough

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

view details

Michael Hough

commit sha 0c6b857d76cd8c4257e974dea08cbac146b744be

Add an install option to skip annotated namespaces And docs to help people decide whether they want it.

view details

push time in a month

PullRequestReviewEvent
PullRequestReviewEvent
PullRequestReviewEvent

push eventIBM/portieris

Stuart Hayton

commit sha 91779260c99555ce1aea0290398ae55687def524

tag specifc policy denies upgrade

view details

push time in a month

PR merged IBM/portieris

tag specifc policy denies upgrade
+1 -1

0 comment

1 changed file

sjhx

pr closed time in a month

delete branch IBM/portieris

delete branch : keysecrets-doc

delete time in 2 months

push eventIBM/portieris

Stuart Hayton

commit sha 897f9f1add548d8a2e3eee4c0bfdea7e3b374aa7

Update POLICIES.md Provide instruction on creating KeySecrets

view details

Stuart Hayton

commit sha 09319ff6c288cae56722758b62c49cfad7fb8835

Update POLICIES.md quotes and such

view details

push time in 2 months

PR merged IBM/portieris

Update POLICIES.md

Provide instruction on creating KeySecrets

+7 -1

0 comment

1 changed file

sjhx

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.

yuzp1996

comment created time in 2 months

push eventIBM/portieris

IsThisTheMatrix

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

view details

push time in 2 months

PR merged IBM/portieris

--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

+1 -1

0 comment

1 changed file

causalityloop

pr closed time in 2 months

PR opened IBM/portieris

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.

+1 -1

0 comment

1 changed file

pr created time in 2 months

create barnchIBM/portieris

branch : molepigeon-patch-5

created branch time in 2 months

delete branch IBM/portieris

delete branch : permissive-policies

delete time in 3 months

push eventIBM/portieris

Stuart Hayton

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

view details

push time in 3 months

PR merged IBM/portieris

Revise default policies

update installed policies in line with https://github.com/IBM/portieris/issues/94 fix https://github.com/IBM/portieris/issues/95

+41 -35

0 comment

1 changed file

sjhx

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

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

+19 -3

0 comment

3 changed files

pr created time in 3 months

create barnchIBM/portieris

branch : nsselector

created branch time in 3 months

PR closed IBM/portieris

Add objectSelector for portieris webhook

Configured to run if anything is different from the labels on the Portieris pods themselves

https://github.com/IBM/portieris/issues/112

+10 -0

1 comment

1 changed file

molepigeon

pr closed time in 3 months

delete branch IBM/portieris

delete branch : selector

delete 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.

molepigeon

comment created time in 3 months

PR opened IBM/portieris

Add objectSelector for portieris webhook

Configured to run if anything is different from the labels on the Portieris pods themselves

https://github.com/IBM/portieris/issues/112

+10 -0

0 comment

1 changed file

pr created time in 3 months

create barnchIBM/portieris

branch : selector

created branch time in 3 months

more