Die Bundestagswahl im September scheint immer noch weit weg zu sein. Doch gerade das Thema Corona könnte die Digitalisierung in den Mittelpunkt des Wahlkampfs rücken. Eine Analyse von Friedhelm Greis (BTW 2021, Urheberrecht)
Quelle: Golem
Vidiyo funktioniert als Augmented-Reality-App und animiert Lego-Figuren mit Tanzmoves zu Songs, die direkt von Universal Music stammen. (Lego, Smartphone)
Quelle: Golem
medium.com – As not all pods can be trusted, this article will show different options to enhance process isolation through the usage of container runtimes other than the default one (runc). We will use Kubernetes…
Quelle: news.kubernauts.io
nethminiromina.medium.com – In Docker, we build docker images and store them in a remote repository such as Docker Hub, GCR or ECR. Same with Helm you can generate Kubernetes packages with Helm called Charts. These charts can…
Quelle: news.kubernauts.io
ismailyenigul.medium.com – Falco is a Kubernetes threat detection engine. Falco supports Kubernetes Audit Events to track the changes defined in k8s audit rules made to your cluster. But unfortunately, AWS EKS is a managed…
Quelle: news.kubernauts.io
Phishing remains among an organization’s most prevalent security threats. At Google, we’ve developed advanced tools to help protect users from phishing attacks, including our Titan Security Keys. With the goal of making security keys even easier to use and more ubiquitous, we’ve recently made it possible to use your phone’s built-in security key to secure your account. Security keys based on FIDO standards are a form of 2-Step verification (2SV) and we consider them to be the strongest, most phishing-resistant method of 2SV because they leverage public key cryptography to verify a user’s identity, and that of the login page, blocking attackers from accessing an account even if they have the username and password. We want as many of our customers as possible to adopt this essential protection and to make them aware of potential risks they are exposed to if they don’t. That’s why today we’re launching a new Recommender into Active Assist, our portfolio of services that help teams operate and optimize their cloud deployments with proactive intelligence instead of unnecessary manual effort. This new “Account security” recommender will automatically detect when a user with elevated permissions, such as a Project Owner, is eligible to use their phone’s built-in security key to better protect their account, but has not yet turned on this important safeguard. Users will see a notification prompting them to enable their phone as a phishing-resistant second factor. This allows organizations to immediately implement this protection and strengthen their security posture using a device end-users almost certainly always have at-hand: their phones. The notification in the Cloud Console looks like this:Acting on the recommendation takes just three simple steps:Click on “Secure Now”, which will open the account’s Security Checkup tool.Follow the instructions located in the “2-Step Verification” tab.Finish the enrollment process.As with all of the recommenders within Active Assist, the goal is to make these recommendations easy to see, understand, and take action on. That means you spend less time on cloud administration, while still achieving a more performant, secure cloud. Here, users can bolster their security posture with just a few clicks by enabling their phone’s built-in security keys. This is similar to what we’ve already empowered security teams to do with Active Assist’s IAM Recommender, which helps greatly reduce unnecessary permissions across your user accounts. This feature will start rolling out to eligible users over the next several weeks. For more information on how to start using your phone’s built-in security key, read our documentation. To learn more about other ways Active Assist can help optimize your cloud operations, check out this blog.
Quelle: Google Cloud Platform
Whether you’re a CISO actively pursuing a cloud security transformation or a CISO supporting a wider digital transformation, you’re responsible for securing information for your company, your partners, and your customers. At Google Cloud, we help you stay ahead of emerging threats, giving you the tools you need to strengthen your security and maintain trust in your company.Enabling a successful digital transformation and migration to the cloud by executing a parallel security transformation ensures that not only can you manage risks in the new environment, but you can also fully leverage the opportunities cloud security offers to modernize your approach and net-reduce your security risk. Our new whitepaper shares our thinking, based on our experiences working with Google Cloud customers, their CISOs, and their teams, on how best to approach a security transformation with this in mind. Here are the key highlights:Prepare your company for cloud securityWhilst it is true that cloud generally, and cloud security specifically, involves the use of sophisticated technologies, it would be wrong to consider cloud security as only a technical problem to solve. In this whitepaper we describe a number of organisational, procedural, people and policy considerations that are critical to achieving the levels of security and risk mitigation you require. As your company starts on, or significantly expands its cloud journey, consider the following;Security Culture. Is security an afterthought, or nice to have, or deemed to be the exclusive responsibility of the security team? Are peer security design and code reviews common and positively viewed, and is it accepted that a culture of inevitability will better prepare you for worst case scenarios?Thinking Differently. Cloud security approaches provide a significant opportunity to debunk a number of longstanding security myths and to adopt modern security practices. By letting go of the traditional security perimeter model, you can direct investments into architectures and models that leverage zero trust concepts, and so dramatically increase the security of your technology more broadly. And by adopting a data-driven assurance approach you can leverage the fact that all deployed cloud technology is explicitly declared and discoverable in data, and build velocity and scale into your assurance processes.Understand how companies evolve with cloudWhen your business moves to the cloud, the way that your whole company works—not just the security team—evolves. As CISO, you need to understand and prepare for these new ways of working so you can integrate and collaborate with your partners and the rest of your company. For example:Accelerated development timelines. Developing and deploying in the cloud can significantly reduce the time between releases, often creating a continuous, iterative release cycle. The shift to this development process—whether it’s called Agile, DevOps, or something else—also represents an opportunity for you to accelerate the development and release of new security features. To take this opportunity, security teams must understand—or even drive—the new release process and timeline, collaborate closely or integrate with development teams, and adopt an iterative approach to security development. Infrastructure managed as code. When servers, racks, and data centers are managed for you in the cloud, your code becomes your infrastructure. Deploying and managing infrastructure as code represents a clear opportunity for your security organization to improve its processes and to integrate more effectively with the software development process. When you deploy infrastructure as code, you can integrate your security policies directly in the code, making security central to both your company’s development process and to any software that your company develops,Evolve your security operating modelTransforming in the cloud also transforms how your security organization works. For example, manual security work will be automated, new roles and responsibilities will emerge, and security experts will partner more closely with development teams. Your organization will also have a new collaborator to work with: your cloud service provider. There are three key considerations:Collaboration with your cloud service provider. Understanding the responsibilities your cloud provider has (“security of the cloud”), and the responsibilities you retain (“security in the cloud”), are important steps to take. Equally, so are the methods you will use to assure the responsibilities that both parties have, including working with your cloud service provider to consume solutions, updates and best practices so that you and your provider have a “shared fate”.Evolving how security roles are performed. In addition to working with a new collaborator in your cloud service provider, your security organization will also change how it works from within. While every organization is different, it is important to consider all parts of the security organisation, from policies and risk management, to security architecture, engineering, operations and assurance, as most roles and responsibilities will need to evolve to some extent.Identifying the optimal security operating model. Your transformation to cloud security is an opportunity to rethink your security operating model. How should security teams work with development teams? Should security functions and operations be centralized or federated? As CISO, you should answer these questions and design your security operating model before you begin moving to the cloud. Our whitepaper helps you choose a cloud-appropriate security operating model by describing the pros and cons of three approaches.Moving to the cloud represents a huge opportunity to transform your company’s approach to security. To lead your security organization and your company through this transformation, you need to think differently about how you work, how you manage risk, and how you deploy your security infrastructure. As CISO, you need to instill a culture of security throughout the company and manage changes in how your company thinks about security and how your company is organized. The recommendations throughout this whitepaper come from Google’s years of leading and innovating in cloud security, in addition to the experience that Google Cloud experts have from their previous roles as CISOs and lead security engineers in major companies that have successfully navigated the journey to cloud. We are excited to collaborate with you on your cloud security transformation.Related ArticleNew whitepaper: Designing and deploying a data security strategy with Google CloudOur new whitepaper helps you start a data security program in a cloud-native way and adjust your existing data security program when you …Read Article
Quelle: Google Cloud Platform
Enterprises are increasingly adopting a service-oriented approach to building applications, composing several different services that span multiple products and environments. For example, a typical deployment can include:Services on Google Cloud, fronted by load balancersThird-party services, such as RedisServices on-premisesServices on other cloudsAs the number and diversity of services grows, it becomes increasingly challenging to maintain an inventory of all of the services across an organization. Last year, we launched Service Directory in beta to help simplify the problem of service management, and it’s now generally available. Service Directory allows you to easily register these services to a single fully managed registry, build a rich ecosystem of services, and uplevel your environment from an infrastructure-centric to a service-centric model.Simplify service naming and lookupWith Service Directory, you can maintain a flexible runtime service inventory. Some of the benefits of using Service Directory include:Human-friendly service naming: Customers can associate human-readable names with their services in Service Directory, as opposed to autogenerated default names. For example, your payments service can be called payments, instead of something like service-b3ada17a-9ada-46b2, making it easier to reference and reason about your servicesEnrich service data with additional properties: In addition to control over names, Service Directory also allows you to annotate a service and its endpoints with additional information beyond names. For example, new services can be given an experimental annotation until they are ready for production, or be given a hipaa-compliant annotation if they are able to handle PHI. Customers can also filter services based on their annotations; for example, if you have services using multiple types of weather data, you can annotate those data sources with fields like sunnyvale-temp, sunnyvale-precipitation, and paloalto-temp. You could then use Service Directory’s query API to find services using only Sunnyvale weather data, by searching for all services annotated with sunnyvale-temp or sunnyvale-precipitation, but not paloalto-temp.Easily resolve services from a variety of clients: Service Directory allows you to resolve services via REST, gRPC, and DNS lookups. In addition, Service Directory’s private DNS zones automatically update DNS records as services change, instead of needing to manually add DNS entries as you add new services.Fully managed: Service Directory is fully managed, allowing you to maintain your service registry with minimal operational overhead.New: automatic service registrationIn this release, you can now automatically register services in Service Directory without needing to write any orchestration code. This feature is available today for Internal TCP/UDP and Internal HTTP(S) load balancers, and will be extended to several other products going forward. Registering services with Service Directory is easy. When you create an Internal Load Balancer forwarding rule, register it with Service Directory by specifying a –service-directory-registration flag with the name of the Service Directory service you want your load balancer to be registered in. This automatically creates a Service Directory entry for your ILB service, and populates it with data such as the forwarding rule’s IP and port. When you delete the forwarding rule, the Service Directory entry is automatically removed as well, without needing to write any cleanup or teardown code.To learn more about Service Directory, visit the documentation, or walk through the configuration guide to get started.
Quelle: Google Cloud Platform
As developers work more and more with containers, it is becoming increasingly important to reduce the time to move from source code to a deployed application. To make building container images faster and easier, we have built technologies like Cloud Build, ko, Jib, Nixery and added support for cloud-native Buildpacks. Some of these tools focus specifically on building container images directly from the source code without a Docker engine or a Dockerfile.The Go programming language specifically makes building container images from source code much easier. This article focuses on how a tool we developed named “ko” can help you deploy services written in Go to Cloud Run faster than Docker build/push, and how it compares to alternatives like Buildpacks.How does ko work?ko is an open-source tool developed at Google that helps you build container images from Go programs and push them to container registries (including Container Registry and Artifact Registry). ko does its job without requiring you to write a Dockerfile or even install Docker itself on your machine.ko is spun off of the go-containerregistry library, which helps you interact with container registries and images. This is for a good reason: The majority of ko’s functionality is implemented using this Go module. Most notably this is what ko does:Download a base image from a container registryStatically compile your Go binaryCreate a new container image layer with the Go binaryAppend that layer to the base image to create a new imagePush the new image to the remote container registryBuilding and pushing a container image from a Go program is quite simple with ko:In the command above, we specified a registry for the resulting image to be published and then specified a Go import path (the same as what we would use in a “go build” command, i.e. the current directory in this case) to refer to the application we want to build. By default, the ko command uses a secure and lean base image from the Distroless collection of images (the gcr.io/distroless/static:nonroot image), which doesn’t contain a shell or other executables in order to reduce the attack surface of the container. With this base image, the resulting container will have CA certificates, timezone data, and your statically-compiled Go application binary.ko also works with Kubernetes quite well. For example, with “ko resolve” and “ko apply” commands you can hydrate your YAML manifests as ko replaces your “image:” references in YAML automatically with the image it builds, so you can deploy the resulting YAML to the Kubernetes cluster with kubectl:Using ko with Cloud RunBecause of ko’s composable nature, you can use ko with gcloud command-line tools to build and push images to Cloud Run with a single command:This works because ko outputs the full pushed image reference to the stdout stream, which gets captured by the shell and passed as an argument to gcloud via the –image flag.Similar to Kubernetes, ko can hydrate your YAML manifests for Cloud Run if you are deploying your services declaratively using YAML:In the command above, “ko resolve” replaces the Go import paths in the “image: …” values of your YAML file, and sends the output to stdout, which is passed to gcloud over a pipe. gcloud reads the hydrated YAML from stdin (due to the “-” argument) and deploys the service to Cloud Run.For this to work, the “image:” field in the YAML file needs to list the import path of your Go program using the following syntax:Ko, compared to its alternativesAs we mentioned earlier, accelerating the refactor-build-deploy-test loop is crucial for developers iterating on their applications. To illustrate the speed gains made possible by using ko (in addition to the time and system resources you’ll save by not having to write a Dockerfile or run Docker), we compared it to two common alternatives:Local docker build and docker push commands (with a Dockerfile)Buildpacks (no Dockerfile, but runs on Docker)Below is the performance comparison for building a sample Go application into a container image and pushing this image to Artifact Registry.Note: In this chart, “cold” builds do not cache layers either in the build machine or in the container registry. In contrast, “warm” builds cache both layers (if caching is enabled by default) and skip pushing the layer blobs to the registry if they already exist.ko vs local Docker Engine: ko wins here by a small margin. This is because the “docker build” command packages your source code into a tarball and sends it to the Docker engine, which either runs natively on Linux or inside a VM on macOS/Windows. Then, Docker builds the image by spinning up a new container for Dockerfile instruction and snapshots the filesystem of the resulting container into an image layer. These steps can take a while.ko does not have these shortcomings; it directly creates the image layers without spinning up any containers and pushes the resulting layer tarballs and image manifest to the registry.In this approach we built and pushed the Go application using the following command:ko vs Buildpacks (on local Docker): Buildpacks help you build images for many languages without having to write a Dockerfile. It’s worth noting that Buildpacks still require Docker to work. Buildpacks work by detecting your language and using a “builder image” that has all the build tools installed, before finally copying the resulting artifacts into a smaller image.In this case, the builder image (gcr.io/buildpacks/builder:v1) is around 500 MB, so it will show up in the “cold” builds. However, even for “warm” builds, Buildpacks use a local Docker engine, which is already slower than ko. And similarly, Buildpacks will run custom logic during the build phase, so it is also slower than Docker.In this approach we built and pushed the Go application using the following command:Conclusionko is part of a larger effort to make developers’ lives easier by simplifying how container images are built. With buildpacks support, you can build container images out of many programming languages without writing Dockerfiles at all, and then you can deploy these images to Cloud Run with a single command.ko helps you build your Go applications into container images and makes it easy to deploy them to Kubernetes or Cloud Run. ko is not limited to the Google Cloud ecosystem: It can authenticate to any container registry and works with any Kubernetes cluster.To learn more, make sure to check out ko documentation at the GitHub repository and try deploying some of your own Go services to Cloud Run.Related ArticleStreamlining Cloud Run development with Cloud CodeCloud Run is now integrated with Cloud Code, making it easier to create new Cloud Run services from your favorite IDE.Read Article
Quelle: Google Cloud Platform
Do you have a Kubernetes application that needs to span multiple clusters? Whether for privacy, scalability, availability, cost management, and data sovereignty reasons, it can be hard for platform teams to architect, implement, operate, and maintain applications across cluster boundaries, as Kubernetes’ Service primitive only enables service discovery within the confines of a single Kubernetes cluster. Today, we are announcing the general availability of multi-cluster services (MCS), a Kubernetes-native cross-cluster service discovery and invocation mechanism for Google Kubernetes Engine (GKE), the most scalable managed Kubernetes offering. MCS extends the reach of the Kubernetes Service primitive beyond the cluster boundary, so you can easily build Kubernetes applications that span multiple clusters. This is especially important for cloud-native applications, which are typically built using containerized microservices. The one constant with microservices is change—microservices are constantly being updated, scaled up, scaled down, and redeployed throughout the lifecycle of an application, and the ability for microservices to discover one another is critical. GKE’s new multi-cluster services capability makes managing cross-cluster microservices-based apps simple. How does GKE MCS work?GKE MCS leverages the existing service primitive that developers and operators are already familiar with, making expanding into multiple clusters consistent and intuitive. Services enabled with this feature are discoverable and accessible across clusters with a virtual IP, matching the behavior of a ClusterIP service within a cluster. Just like your existing services, services configured to use MCS are compatible with community-driven, open APIs, ensuring your workloads remain portable. The GKE MCS solution leverages environs to group clusters and is powered by the same technology offered by Traffic Director, Google Cloud’s fully managed, enterprise-grade platform for global application networking.Common MCS use casesMercari, a leading e-commerce company and an early adopter of MCS: “We have been running all our microservices in a single multi-tenant GKE cluster. For our next-generation Kubernetes infrastructure, we are designing multi-region homogeneous and heterogeneous clusters. Seamless inter-cluster east-west communication is a prerequisite and multi-cluster Services promise to deliver. Developers will not need to think about where the service is running. We are very excited at the prospect.” – Vishal Banthia, Engineering Manager, Platform Infra, Mercari We are excited to see how you use MCS to deploy services that span multiple clusters to deliver solutions optimized for your business needs. Here are some popular use cases we have seen our customers enable with GKE MCS.High availability – Running the same service across clusters in multiple regions provides improved fault tolerance. In the event that a service in one cluster is unavailable, the request can fail over and be served from another cluster (or clusters). With MCS, it’s now possible to manage the communication between services across clusters, to improve the availability and resiliency of your applications to meet service level objectives.Stateful and stateless services – Stateful and stateless services have different operational dependencies and complexities and present different operational tradeoffs. Typically, stateless services have less of a dependency on migrating storage, making it easier to scale, upgrade and migrate a workload with high availability. MCS lets you separate an application into separate clusters for stateful and stateless workloads, making them easier to manage.Shared services – Increasingly, customers are spinning up separate Kubernetes clusters to get higher availability, better management of stateful and stateless services, and easier compliance with data sovereignty requirements. However, many services such as logging, monitoring (Prometheus), secrets management (Vault), or DNS are often shared amongst all clusters to simplify operations and reduce costs. Instead of each cluster requiring its own local service replica, MCS makes it easy to set up common shared services in a separate cluster that is used by all functional clusters.Migration – Modernizing an existing application into a containerized microservices-based architecture often requires services to be deployed across multiple Kubernetes clusters. MCS provides a mechanism to help bridge the communication between those services, making it easier to migrate your applications—especially when the same service can be deployed in two different clusters and traffic is allowed to shift.Multi-cluster Services & Multi-cluster IngressMCS also complements [Multi-cluster Ingress] with multi-cluster load balancing for both East-West and North-South traffic flows. Whether your traffic flows from the internet across clusters, within the VPC between clusters, or both, GKE provides multi-cluster networking that is deeply integrated and Kubernetes-native. Get started with GKE multi-cluster services, todayYou can start using multi-cluster services in GKE today and gain the benefits of higher availability, better management of shared services, and easier compliance for data sovereignty requirements of your applications.Thanks to Maulin Patel, Product Manager, for his contributions to this blog post.Related ArticleGKE best practices: Exposing GKE applications through Ingress and ServicesWe’ll walk through the different factors you should consider when exposing applications on GKE, explain how they impact application expos…Read Article
Quelle: Google Cloud Platform
