profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/gcapizzi/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

gcapizzi/containers-study-path 8

A study path to get started on containers.

gcapizzi/awesome-bread 6

A list of my favourite resources about baking bread&c.

gcapizzi/atibi 1

Our local transport company shouldn't have used Flash for its home page. Here is a clone in HTML, CSS and Javascript/JQuery.

gcapizzi/CIS194 1

My solutions to the CIS194 course exercises

edwardecook/docs-book-cloudfoundry 0

The bookbinder repository for open source Cloud Foundry documentation

eirini-playground/tinypaas 0

Tiny little PaaS with a GitOps feeling

flangewad/cf-deployment 0

The canonical open source deployment manifest for Cloud Foundry

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 729bb3d9a4f7b5e23efa71bad6a5470a88f428ce

withExistingDestination -> ifDestinationExists

view details

Giuseppe Capizzi

commit sha 9777a5668389109de5bbaab4e54f1e143135cfe4

Always use the chess namespace in tests

view details

Giuseppe Capizzi

commit sha 360a0e56409a1d6627722d30101c4c5f1c58d339

Introduce knight moves

view details

push time in 17 hours

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha c9928bddc79ec56bc6e0917726877b991a2e050d

Implement FEN rendering

view details

Giuseppe Capizzi

commit sha e480dd43d38d53b4e6705b28867156ea70c6e977

Formatting

view details

Giuseppe Capizzi

commit sha a44e3db5df19024f4d6c8896b72685e79af9af11

Implement en passant captures

view details

push time in 2 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 5b68ce13127ba056dacdcdf3a4d2d43c35d90b19

Introduce move turns

view details

push time in 2 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 35df6800eb237b293787156ee9a7a29af8259c15

Improve tests

view details

Giuseppe Capizzi

commit sha 110eab80fc908262238c65b27529bdde70978473

Black pawn moves

view details

Giuseppe Capizzi

commit sha d3539810705547e3d278303385ecde58a24b17fb

Improve test

view details

Giuseppe Capizzi

commit sha 86a77269f366f2d9183c5a78423275711921837b

Remove redundant check

view details

push time in 3 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha b65661174ca85e68a15c3384a20d2f43b52cb714

Add better FEN test

view details

push time in 3 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 1e6efe9b286956876a8667b371a845b0736b6713

Introduce FEN parsing

view details

Giuseppe Capizzi

commit sha d62cbc195c550234eefaca380cc7f7787f4a18e0

Add Game.removePiece()

view details

push time in 3 days

issue commentcloudfoundry/cf-crd-explorations

Explore: integrating `$KUBECONFIG`

Today we proved that it is relatively easy for us to support both exec plugins and gcp auth-providers in the cf CLI. By leveraging the ConnectionWrapper interface, we can replace the UAA authentication logic with ours! See here for our implementation.

Credentials are sent to the shim as a serialised ExecCredentials object, which can contain either client certificates or a token. The serialised object is encoded in Base64 and sent in the Authorization header with a custom execcredentials prefix. Here is the code.

We still haven't tried to integrate with the following authentication configurations:

  • Static client credentials or tokens: these should be trivial, and would neatly fit into the ExecCredentials type.
  • Azure auth-provider: not worth implementing as it's deprecated and can be converted to an exec config using Azure/kubelogin
  • OIDC auth-provider: this is a tricky one, as it requires token refreshing, which in turn would require us to persist the refreshed token in $KUBECONFIG. We're not sure writing $KUBECONFIG from cf is the right thing to do though.

To choose witch user to use to authenticate, we're referring to current-context for now. We can see how it could be useful to specify the context from the CLI or to configure different contexts in kubectl and in cf, but we need to investigate more about this. Contexts also point to clusters, which is not information we want to use as the shim endpoint is not going to be the same as the Kubernetes API endpoint. Shall we send the Kubernetes API endpoint to the shim to use to make its requests? This would make the shim multi-cluster, but we're not sure it's a good idea.

This direction looks a lot more promising than trying to integrate via OIDC, and we think it is the way to go. Supporting static credentials + exec plugins + the gke auth-provider would already cover most vendors. Adding the oidc auth-provider would cover pretty much all of them.

gcapizzi

comment created time in 4 days

push eventeirini-forks/cli

Kieron Browne

commit sha ebbc342a438438418c97ff9da202a7e8e3d0e4dd

Use an auth wrapper to grab dtls from kube config Gets creds from an exec plugin or GCP auth-provider. Sends them as a serialised ExecCredential obj to Shim. Co-authored-by: Giuseppe Capizzi <gcapizzi@pivotal.io>

view details

push time in 4 days

push eventcloudfoundry/cf-crd-explorations

Giuseppe Capizzi

commit sha f071dc14f95b3b510ac9add3c9cf2340dedb6991

Accept creds from an ExecCredential structure We've hardcoded the pinniped impersonation proxy URL and CAData for now. This needs to come from config Co-authored-by: Kieron Browne <kbrowne@vmware.com>

view details

push time in 4 days

issue commentcloudfoundry/cf-crd-explorations

Explore: integrating `$KUBECONFIG`

In-tree auth-provider plugins are deprecated in 1.22! This means providers will have to migrate to exec plugins, which is great news.

In particular, Azure already provides Azure/kubelogin and will probably have to do this in az eventually, while Google still haven't done anything. The deprecated plugins will be removed in 1.25, which we expect to happen in ~1 year, so we might have to backfill something in until then. Given the GCP auth-provider plugin already looks a lot like an exec plugin (only difference is the JSON produced), we think we can easily support it.

gcapizzi

comment created time in 4 days

push eventcloudfoundry-incubator/eirini-controller

Come-On Eirini

commit sha bfee92d7f270c7d3d5e68ad2e81c3b0a6fe258af

Bump go packages

view details

push time in 4 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 44606bd197cc0032524e1f9313b3578c76174547

New move validation logic

view details

push time in 5 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha a1ba7e4ae58ec7b041e97e0280a57d3f1462d0b7

Game.fromStartingPosition -> startingPosition

view details

Giuseppe Capizzi

commit sha 1b6e47ffda9047aee97695e6fda8ebc42a5a126a

Refactor Square.fromString()

view details

Giuseppe Capizzi

commit sha 9b793a618d02218d55f1d04d4c57a55791a694c6

Add Square.toString()

view details

Giuseppe Capizzi

commit sha 39621f42805ce6a5c04c1da45f8aae57c088b059

Add other toString() implementations

view details

Giuseppe Capizzi

commit sha f588a8b3917df62cd835c48009a102581df5d7ed

Only capture opponent pawns

view details

push time in 5 days

issue commentcloudfoundry/cf-crd-explorations

Spike: supporting non-OIDC clusters with Pinniped

@kieron-dev @mnitchev how do you feel about updating this doc with your findings?

gcapizzi

comment created time in 6 days

issue openedcloudfoundry/cf-crd-explorations

Explore: integrating `$KUBECONFIG`

Background

Authentication in EKS, AKS and GKE

Our previous explore have unveiled that the way different providers integrate with identity providers can be very different. In particular:

  • Amazon EKS allows to configure a third-party OpenID Connect provider very easily. It's the only provider we've seen so far with full OIDC support. When this is not done, it integrates with Amazon's IAM using an OAuth 2.0-based system.
  • Microsoft AKS is tightly integrated with Azure's authentication solution, Azure Active Directory, and doesn't allow to use third parties. While AAD tokens are valid OIDC tokens, it is not possible (or maybe just very hard / cumbersome) to authenticate to AAD using a standard OIDC flow. Instead, users are recommended to use the az CLI.
  • Google GKE uses its own authentication solution which is not OIDC, but is still OAuth 2.0. Third parties are not supported. Users log in using the gcloud CLI (although standard OAuth 2.0 flow might be supported?).

What all these providers have in common is the fact that they use $KUBECONFIG as their point of integration with the user. Instead of implementing standard OpenID Connect or OAuth flows for authentication and let the user handle their $KUBECONFIG (maybe via something like kubelogin), they provide proprietary ways to generate the $KUBECONFIG directly.

Ways of configuring authentication in $KUBECONFIG

User authentication configuration is stored in the AuthInfo struct. You can see there's different ways to do this:

  • Client certificates, via the client-certificate* fields
  • Bearer tokens via the token* fields
  • Basic Auth via the username and password fields
  • Custom plugins shipped with client-go via the auth-provider field
  • Custom plugins as executables on the user's machine via the exec field

auth-provider plugins

These are implementations of the AuthProvider interface, shipped with client-go. AKS and GKE use these.

Curiously there's also an OIDC implementation! It does not implement the OIDC/OAuth authentication flow, but expects the ID and refresh tokens as inputs and is capable of refreshing the token. For some reason kubelogin doesn't use this, but an exec plugin.

Example configs

AKS
auth-provider:
  config:
    apiserver-id: XXX
    client-id: XXX
    config-mode: '1'
GKE
auth-provider:
  config:
    cmd-args: config config-helper --format=json
    cmd-path: /usr/lib/google-cloud-sdk/bin/gcloud
    expiry: "2021-07-28T14:38:50Z"
    expiry-key: '{.credential.token_expiry}'
    token-key: '{.credential.access_token}'

exec plugins

These plugins can be implemented as executables which can be invoked by client-go/kubectl and return the necessary credentials via stdout. The output needs to deserialise to the ExecCredentials type, which can contain a token or a client certificate.

This is what EKS uses by default. kubelogin is an exec plugin too. AKS can be switched to this style of plugin via their kubelogin tool (not the same as int128/kubelogin), which migrates the users's $KUBECONFIG from using auth-provider to using exec.

Example configs

EKS
exec:
  apiVersion: client.authentication.k8s.io/v1alpha1
  args:
  - --region
  - us-west-2
  - eks
  - get-token
  - --cluster-name
  - cf-on-k8s-test
  command: aws
  env: null
  provideClusterInfo: false
int128/kubelogin
exec:
  apiVersion: client.authentication.k8s.io/v1beta1
  command: kubectl
  args:
  - oidc-login
  - get-token
  - --oidc-issuer-url=XXX
  - --oidc-client-id=XXX
  - --oidc-client-secret=XXX
AKS + Azure/kubelogin
exec:
  apiVersion: client.authentication.k8s.io/v1beta1
  args:
  - get-token
  - --server-id
  - XXX
  - --login
  - azurecli
  command: kubelogin
  env: null
  provideClusterInfo: false

Question

  • How feasible is it to integrate the cf CLI directly with $KUBECONFIG?
  • Can we achieve a flow where the user, after logging in with the provider tool (aws/az/gcloud) can use thecf` CLI straight away?
  • If not, can we get away with a one-off setup command?

created time in 6 days

issue commentcloudfoundry/cf-crd-explorations

Explore: check OIDC support in AKS and EKS

Corollary

I finally found out how the config mentioned at the end of https://github.com/cloudfoundry/cf-crd-explorations/issues/45#issuecomment-884979684 works: it is literally baked into client-go and thus kubectl!

gcapizzi

comment created time in 6 days

issue closedcloudfoundry/cf-crd-explorations

Explore: check OIDC support in AKS and EKS

Background

As we're betting on OpenID Connect (OIDC) as our authentication method, we want to make sure it is supported by all major vendors. This is not the case for Google Kubernetes Engine (GKE), but it should be for Microsoft Azure Kubernetes Service (AKS) and Amazon Elastic Kubernetes Service (EKS).

Questions

  • Is it really possible to configure AKS and EKS clusters to use OIDC?
  • If yes, where is this documented?

closed time in 7 days

gcapizzi

issue commentcloudfoundry/cf-crd-explorations

Explore: check OIDC support in AKS and EKS

Microsoft AKS, part V

I created a cluster associated to an Application, but still no luck. Even if this worked, it definitely wouldn't have been the default setup.

This draws me to the conclusion that, while we might rely on all our clusters being authenticated via OIDC (or maybe even OAuth 2.0?), we can't rely on all Identity Providers to support standard authentication flows. AKS is one of these cases: authentication happens via OIDC, the tokens are OIDC tokens, but the way users get their token has nothing to do with the standard flows.

One thing that all these providers do have in common is that they produce a valid $KUBECONFIG. The range of configurations is wide though: some directly put the tokens there, some put client certificates, some use client-go credential plugins, and some use something else entirely!

We should explore all these configurations and evaluate how feasible it is to leverage $KUBECONFIG. I couldn't find any documentation about all the authentication configuration options available, which makes this even more of a challenge.

gcapizzi

comment created time in 7 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 30f7ce82d594ace7b3b78f551ae1388143d983e9

Add README.md

view details

push time in 7 days

issue commentcloudfoundry/cf-crd-explorations

Explore: check OIDC support in AKS and EKS

Microsoft AKS, part IV

This example seems to imply that regular OIDC flows are supported. In the example, they add a Microsoft-specific scope, called https://graph.microsoft.com/mail.read. This makes me wonder if any AKS-specific scopes exist.

Also, registered applications can (have to?) be given permissions, which match the scopes that they can request. I wasn't able to find any mention of AKS in the list though.

gcapizzi

comment created time in 8 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 090dcaaa9004616fa212ec7d2c54c467d50a7054

getPieceAt -> getPiece

view details

Giuseppe Capizzi

commit sha b53d966d1730234083be349a548ce80710ba7bd8

Game.board should be private

view details

Giuseppe Capizzi

commit sha 58f46f359e936fd0b2b39b26afd458bd08cf43bc

Make Piace.colour and .type public but readonly

view details

Giuseppe Capizzi

commit sha 941c6006441122a2486cec71c5304fd7d31623a7

Introduce Game.move()

view details

Giuseppe Capizzi

commit sha eaf5f915413623fe1ca8c0abf45b860d9f20bd4d

White pawn moves

view details

push time in 8 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha de082b5d42aa5c29127bab4720f0ab32c20cbed0

Extract Game to its own file

view details

push time in 9 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 442df208e7671afad05be51bb452ad7936fe5304

Extract Game to its own file

view details

push time in 9 days

push eventgcapizzi/ivanchuk

Giuseppe Capizzi

commit sha 5dc6d4ab0b3d8c47740f3fde447a9a07d5cbc02b

Location -> Square

view details

push time in 9 days

create barnchgcapizzi/ivanchuk

branch : main

created branch time in 9 days

created repositorygcapizzi/ivanchuk

Type-safe chess login in Typescript.

created time in 9 days

issue commentcloudfoundry/cf-crd-explorations

Explore: check OIDC support in AKS and EKS

Microsoft AKS, part III

I have tried adding the following value of claims to the authentication URL:

{
  "id_token": {
    "acr": null,
    "aio": null,
    "altsecid": null,
    "appid": null,
    "appidacr": null,
    "groups": null,
    "puid": null,
    "scp": null,
    "wids": null
  }
}

but still no luck 😕 this is what it looks like in the URL:

https://login.windows.net/XXX/oauth2/authorize?claims=%7B%22id_token%22%3A%7B%22acr%22%3Anull%2C%22aio%22%3Anull%2C%22altsecid%22%3Anull%2C%22appid%22%3Anull%2C%22appidacr%22%3Anull%2C%22groups%22%3Anull%2C%22puid%22%3Anull%2C%22scp%22%3Anull%2C%22wids%22%3Anull%7D%7D&client_id=XXX&redirect_uri=http%3A%2F%2Flocalhost%3A5555%2Fcallback&response_type=code&scope=openid+profile+email&state=I+wish+to+wash+my+irish+wristwatch
gcapizzi

comment created time in 11 days

push eventcloudfoundry-incubator/eirini-controller

Come-On Eirini

commit sha 5d26f36d58f545d54e0469752e0a801e46302001

Bump go packages

view details

push time in 11 days

issue commentcloudfoundry/cf-crd-explorations

Explore: check OIDC support in AKS and EKS

Microsoft AKS, part II

I have managed to get ID tokens via both cf oidc-login and the OpenID Connect Playground! Bad news is they don't seem to work 😕

kubectl --token "XXX" get nodes
error: You must be logged in to the server (Unauthorized)
gcapizzi

comment created time in 12 days