Skip to main content

Home/ Larvata/ Group items tagged oauth

Rss Feed Group items tagged

張 旭

Ingress - Kubernetes - 0 views

  • An API object that manages external access to the services in a cluster, typically HTTP.
  • load balancing
  • SSL termination
  • ...62 more annotations...
  • name-based virtual hosting
  • Edge routerA router that enforces the firewall policy for your cluster.
  • Cluster networkA set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes networking model.
  • A Kubernetes ServiceA way to expose an application running on a set of Pods as a network service. that identifies a set of Pods using labelTags objects with identifying attributes that are meaningful and relevant to users. selectors.
  • Services are assumed to have virtual IPs only routable within the cluster network.
  • Ingress exposes HTTP and HTTPS routes from outside the cluster to services within the cluster.
  • Traffic routing is controlled by rules defined on the Ingress resource.
  • An Ingress can be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting.
  • Exposing services other than HTTP and HTTPS to the internet typically uses a service of type Service.Type=NodePort or Service.Type=LoadBalancer.
  • You must have an ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.
  • As with all other Kubernetes resources, an Ingress needs apiVersion, kind, and metadata fields
  • Ingress frequently uses annotations to configure some options depending on the Ingress controller,
  • Ingress resource only supports rules for directing HTTP traffic.
  • An optional host.
  • A list of paths
  • A backend is a combination of Service and port names
  • has an associated backend
  • Both the host and path must match the content of an incoming request before the load balancer directs traffic to the referenced Service.
  • HTTP (and HTTPS) requests to the Ingress that matches the host and path of the rule are sent to the listed backend.
  • A default backend is often configured in an Ingress controller to service any requests that do not match a path in the spec.
  • An Ingress with no rules sends all traffic to a single default backend.
  • Ingress controllers and load balancers may take a minute or two to allocate an IP address.
  • A fanout configuration routes traffic from a single IP address to more than one Service, based on the HTTP URI being requested.
  • nginx.ingress.kubernetes.io/rewrite-target: /
  • describe ingress
  • get ingress
  • Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address.
  • route requests based on the Host header.
  • an Ingress resource without any hosts defined in the rules, then any web traffic to the IP address of your Ingress controller can be matched without a name based virtual host being required.
  • secure an Ingress by specifying a SecretStores sensitive information, such as passwords, OAuth tokens, and ssh keys. that contains a TLS private key and certificate.
  • Currently the Ingress only supports a single TLS port, 443, and assumes TLS termination.
  • An Ingress controller is bootstrapped with some load balancing policy settings that it applies to all Ingress, such as the load balancing algorithm, backend weight scheme, and others.
  • persistent sessions, dynamic weights) are not yet exposed through the Ingress. You can instead get these features through the load balancer used for a Service.
  • review the controller specific documentation to see how they handle health checks
  • edit ingress
  • After you save your changes, kubectl updates the resource in the API server, which tells the Ingress controller to reconfigure the load balancer.
  • kubectl replace -f on a modified Ingress YAML file.
  • Node: A worker machine in Kubernetes, part of a cluster.
  • in most common Kubernetes deployments, nodes in the cluster are not part of the public internet.
  • Edge router: A router that enforces the firewall policy for your cluster.
  • a gateway managed by a cloud provider or a physical piece of hardware.
  • Cluster network: A set of links, logical or physical, that facilitate communication within a cluster according to the Kubernetes networking model.
  • Service: A Kubernetes Service that identifies a set of Pods using label selectors.
  • An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting.
  • An Ingress does not expose arbitrary ports or protocols.
  • You must have an Ingress controller to satisfy an Ingress. Only creating an Ingress resource has no effect.
  • The name of an Ingress object must be a valid DNS subdomain name
  • The Ingress spec has all the information needed to configure a load balancer or proxy server.
  • Ingress resource only supports rules for directing HTTP(S) traffic.
  • An Ingress with no rules sends all traffic to a single default backend and .spec.defaultBackend is the backend that should handle requests in that case.
  • If defaultBackend is not set, the handling of requests that do not match any of the rules will be up to the ingress controller
  • A common usage for a Resource backend is to ingress data to an object storage backend with static assets.
  • Exact: Matches the URL path exactly and with case sensitivity.
  • Prefix: Matches based on a URL path prefix split by /. Matching is case sensitive and done on a path element by element basis.
  • multiple paths within an Ingress will match a request. In those cases precedence will be given first to the longest matching path.
  • Hosts can be precise matches (for example “foo.bar.com”) or a wildcard (for example “*.foo.com”).
  • No match, wildcard only covers a single DNS label
  • Each Ingress should specify a class, a reference to an IngressClass resource that contains additional configuration including the name of the controller that should implement the class.
  • secure an Ingress by specifying a Secret that contains a TLS private key and certificate.
  • The Ingress resource only supports a single TLS port, 443, and assumes TLS termination at the ingress point (traffic to the Service and its Pods is in plaintext).
  • TLS will not work on the default rule because the certificates would have to be issued for all the possible sub-domains.
  • hosts in the tls section need to explicitly match the host in the rules section.
張 旭

OmniAuth: Overview · plataformatec/devise Wiki - 0 views

  • omniauth-provider
  • add the columns "provider" and "uid" to your User model
  • declare the provider in your config/initializers/devise.rb and require it
  • ...17 more annotations...
  • set it explicitly with the :strategy_class option
  • explicitly tell OmniAuth where to locate your ca_certificates file
  • make your model (e.g. app/models/user.rb) omniauthable
  • devise_for :users was already added to your config/routes.rb
  • user_omniauth_authorize_path(provider) user_omniauth_callback_path(provider)
  • devise does not create *_url methods
  • The symbol passed to the user_omniauth_authorize_path method matches the symbol of the provider passed to Devise's config block
  • After inserting their credentials, they will be redirected back to your application's callback method
  • tell Devise in which controller we will implement Omniauth callbacks
  • find_for_facebook_oauth
  • implement the method below in your model
  • All information retrieved from Facebook by OmniAuth is available as a hash at request.env["omniauth.auth"]
  • Devise removes all the data starting with "devise." from the session whenever a user signs in, so we get automatic session clean up
  • We pass the :event => :authentication to the sign_in_and_redirect method to force all authentication callbacks to be called
  • tries to find an existing user by provider and uid or create one with a random password otherwise.
  • Devise's RegistrationsController by default calls "User.new_with_session" before building a resource
  • if we need to copy data from session whenever a user is initialized before sign up, we just need to implement new_with_session in our model
張 旭

JSON Web Token Introduction - jwt.io - 0 views

  • a stateless authentication mechanism as the user state is never saved in server memory
  • In authentication, when the user successfully logs in using their credentials, a JSON Web Token will be returned and must be saved locally (typically in local storage, but cookies can be also used), instead of the traditional approach of creating a session in the server and returning a cookie.
  • ser agent should send the JWT, typically in the Authorization header using the Bearer schema.
  • ...2 more annotations...
  • It doesn't matter which domains are serving your APIs, so Cross-Origin Resource Sharing (CORS) won't be an issue as it doesn't use cookies.
  • WT and SAML tokens can use a public/private key pair in the form of a X.509 certificate for signing.
張 旭

Keycloak and FreeIPA Intro - scott poore's blog - 0 views

  • Keycloak is an “Open source identity and access management” solution.
  • setup a central Identity Provider (IdP) that applications acting as Service Providers (SP) use to authenticate or authorize user access.
  • FreeIPA does a LOT more than just provide user info though.  It can manage user groups, service lists, hosts, DNS, certificates, and much, much, more.
  • ...5 more annotations...
  • IPA – refers to the FreeIPA Master Server.
  • IdP – as mentioned earlier, IdP stands for Identity Provider.
  • SP – stands for Service Provider.   This can be a java application, jboss, etc.  It can also be a simple Apache web server
  • SAML – stands for Security Assertion Markup Language and refers to mod_auth_mellon here.  This provides the SSO functionality.
  • Openidc – stands for OpenID Connect.
1 - 5 of 5
Showing 20 items per page